H3C SR8800-F Routers. Comware 7 BRAS Services Configuration Guide. New H3C Technologies Co., Ltd.

Transcription

1 H3C SR8800-F Routers Comware 7 BRAS Services Configuration Guide New H3C Technologies Co., Ltd. Software version: SR8800FS-CMW710-R7655P05 or later Document version: 6W

2 Copyright 2017, New H3C Technologies Co., Ltd. and its licensors All rights reserved No part of this manual may be reproduced or transmitted in any form or by any means without prior written consent of New H3C Technologies Co., Ltd. Trademarks H3C,, H3CS, H3CIE, H3CNE, Aolynk,, H 3 Care,, IRF, NetPilot, Netflow, SecEngine, SecPath, SecCenter, SecBlade, Comware, ITCMM and HUASAN are trademarks of New H3C Technologies Co., Ltd. All other trademarks that may be mentioned in this manual are the property of their respective owners Notice The information in this document is subject to change without notice. Every effort has been made in the preparation of this document to ensure accuracy of the contents, but all statements, information, and recommendations in this document do not constitute the warranty of any kind, express or implied.

3 Preface This configuration guide describes fundamentals and configuration of BRAS features. The broadband remote access server (BRAS) provides a basic access approach to the backbone network and management features for the broadband access network. This preface includes the following topics about the documentation: Audience. Conventions Obtaining documentation Technical support Documentation feedback Audience This documentation is intended for: Network planners. Field technical support and servicing engineers. Network administrators working with the routers. Conventions The following information describes the conventions used in the documentation. Command conventions Convention Boldface Italic Description Bold text represents commands and keywords that you enter literally as shown. Italic text represents arguments that you replace with actual values. [ ] Square brackets enclose syntax choices (keywords or arguments) that are optional. { x y... } [ x y... ] { x y... } * [ x y... ] * &<1-n> Braces enclose a set of required syntax choices separated by vertical bars, from which you select one. Square brackets enclose a set of optional syntax choices separated by vertical bars, from which you select one or none. Asterisk marked braces enclose a set of required syntax choices separated by vertical bars, from which you select a minimum of one. Asterisk marked square brackets enclose optional syntax choices separated by vertical bars, from which you select one choice, multiple choices, or none. The argument or keyword and argument combination before the ampersand (&) sign can be entered 1 to n times. # A line that starts with a pound (#) sign is comments. GUI conventions Convention Boldface Description Window names, button names, field names, and menu items are in Boldface. For

4 Convention > Description example, the New User window opens; click OK. Multi-level menus are separated by angle brackets. For example, File > Create > Folder. Symbols Convention WARNING! CAUTION: IMPORTANT: NOTE: TIP: Description An alert that calls attention to important information that if not understood or followed can result in personal injury. An alert that calls attention to important information that if not understood or followed can result in data loss, data corruption, or damage to hardware or software. An alert that calls attention to essential information. An alert that contains additional or supplementary information. An alert that provides helpful information. 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 Wireless terminator unit. T 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.

5 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. Obtaining documentation To access the most up-to-date H3C product documentation, go to the H3C website at To obtain information about installation, configuration, and maintenance, click To obtain software version information such as release notes, click Technical support Documentation feedback You can your comments about product documentation to We appreciate your comments.

6 Contents BRAS services overview 1 BRAS network 1 BRAS components 2 BRAS services 2 Configuring AAA 5 About AAA 5 AAA implementation 5 AAA network diagram 5 RADIUS 6 HWTACACS 9 LDAP 12 User management based on ISP domains and user access types 15 Authentication, authorization, and accounting methods 15 AAA for MPLS L3VPNs 17 Protocols and standards 17 AAA tasks at a glance 18 Configuring local users 19 About local users 19 Local user configuration tasks at a glance 20 Configuring attributes for device management users 20 Configuring attributes for network access users 21 Configuring local guest attributes 22 Configuring user group attributes 23 Managing local guests 25 Display and maintenance commands for local users and local user groups 26 Configuring RADIUS 27 RADIUS tasks at a glance 27 Configuring a test profile for RADIUS server status detection 27 Creating a RADIUS scheme 28 Specifying the RADIUS authentication servers 28 Specifying the RADIUS accounting servers 29 Specifying the shared keys for secure RADIUS communication 30 Specifying an MPLS L3VPN instance for the scheme 30 Setting the username format and traffic statistics units 31 Setting the maximum number of RADIUS request transmission attempts 31 Setting the maximum number of real-time accounting attempts 32 Configuring RADIUS stop-accounting packet buffering 32 Setting the maximum number of pending RADIUS requests 33 Setting the status of RADIUS servers 33 Enabling the RADIUS server load sharing feature 35 Specifying the source IP address for outgoing RADIUS packets 36 Setting RADIUS timers 37 Configuring the RADIUS accounting-on feature 38 Interpreting the RADIUS class attribute as CAR parameters 38 Configuring the Login-Service attribute check method for SSH, FTP, and terminal users 39 Configuring the MAC address format for RADIUS attribute Configuring the format for RADIUS attribute Setting the data measurement unit for the Remanent_Volume attribute 40 Specifying a server version for interoperating with servers with a vendor ID of Configuring the RADIUS attribute translation feature 41 Configuring the RADIUS session-control feature 43 Configuring the RADIUS DAS feature 43 Changing the DSCP priority for RADIUS packets 44 Configuring the device to preferentially process RADIUS authentication requests 44 Enabling SNMP notifications for RADIUS 45 Display and maintenance commands for RADIUS 45 i

7 Configuring HWTACACS 46 HWTACACS tasks at a glance 46 Creating an HWTACACS scheme 46 Specifying the HWTACACS authentication servers 46 Specifying the HWTACACS authorization servers 47 Specifying the HWTACACS accounting servers 48 Specifying the shared keys for secure HWTACACS communication 48 Specifying an MPLS L3VPN instance for the scheme 49 Setting the username format and traffic statistics units 49 Configuring HWTACACS stop-accounting packet buffering 50 Specifying the source IP address for outgoing HWTACACS packets 50 Setting HWTACACS timers 51 Display and maintenance commands for HWTACACS 52 Configuring LDAP 53 LDAP tasks at a glance 53 Creating an LDAP server 53 Configuring the IP address of the LDAP server 53 Specifying the LDAP version 54 Setting the LDAP server timeout period 54 Configuring administrator attributes 54 Configuring LDAP user attributes 55 Configuring an LDAP attribute map 56 Creating an LDAP scheme 56 Specifying the LDAP authentication server 57 Specifying the LDAP authorization server 57 Specifying an LDAP attribute map for LDAP authorization 57 Display and maintenance commands for LDAP 57 Configuring AAA methods for ISP domains 58 Creating an ISP domain 58 Configuring ISP domain attributes 59 Configuring authentication methods for an ISP domain 62 Configuring authorization methods for an ISP domain 64 Configuring accounting methods for an ISP domain 66 Display and maintenance commands for ISP domains 68 Setting the maximum number of concurrent login users 69 Configuring the local bill cache feature 69 About local bill cache 69 Procedure 69 Display and maintenance commands for local bill cache 70 Configuring a NAS-ID 70 About NAS-IDs 70 Configuring a NAS-ID profile 70 Setting the NAS-ID on an interface 71 Setting the NAS-ID in an ISP domain 71 Configuring the device ID 72 AAA configuration examples 72 Example: Configuring authentication and authorization for SSH users by a RADIUS server 72 Example: Configuring local authentication and authorization for SSH users 75 Example: Configuring AAA for SSH users by an HWTACACS server 76 Example: Configuring authentication for SSH users by an LDAP server 77 Example: Configuring AAA for PPP users by an HWTACACS server 82 Troubleshooting RADIUS 83 RADIUS authentication failure 83 RADIUS packet delivery failure 84 RADIUS accounting error 84 Troubleshooting HWTACACS 85 Troubleshooting LDAP 85 LDAP authentication failure 85 Appendixes 86 Appendix A Commonly used RADIUS attributes 86 Appendix B Descriptions for commonly used standard RADIUS attributes 87 Appendix C RADIUS subattributes (vendor ID 25506) 89 ii

8 Configuring ANCP 92 About ANCP 92 How ANCP works 92 Protocols and standards 93 ANCP tasks at a glance 93 Enabling the ANCP server 94 Configuring the adjacency timer 94 Configuring the maximum number of retransmission attempts 94 Creating an ANCP neighbor 95 Configuring an ANCP neighbor ID 95 About ANCP neighbor IDs 95 Restrictions and guidelines 95 Procedure 95 Configuring a source interface for a neighbor 95 About the sources interface for a neighbor 95 Restrictions and guidelines for the source interface of a neighbor 96 Configuring the global source interface in system view 96 Configuring a source interface for a neighbor in neighbor view 96 Configuring the DSL entry aging time 96 Configuring ANCP OAM 97 Assigning a service profile to a DSL 97 Display and maintenance commands for ANCP 97 ANCP configuration examples 98 Example: Configuring ANCP 98 DHCP overview 101 DHCP network model 101 DHCP address allocation 101 Allocation mechanisms 101 IP address allocation process 102 IP address lease extension 102 DHCP message format 103 DHCP options 104 Common DHCP options 104 Custom DHCP options 104 Vendor-specific option (Option 43) 105 Relay agent option (Option 82) 106 Option Protocols and standards 107 Configuring the DHCP server 108 About DHCP server 108 DHCP address assignment mechanisms 108 Principles for selecting an address pool 109 IP address allocation sequence 110 DHCP server tasks at a glance 110 Creating a DHCP user class 111 Configuring an address pool on the DHCP server 111 DHCP address pool tasks at a glance 111 Creating a DHCP address pool 112 Specifying IP address ranges for a DHCP address pool 112 Specifying gateways for DHCP clients 115 Specifying a domain name suffix for DHCP clients 115 Specifying DNS servers for DHCP clients 116 Specifying WINS servers and NetBIOS node type for DHCP clients 116 Specifying BIMS server for DHCP clients 116 Specifying the configuration file for DHCP client auto-configuration 117 Specifying a server for DHCP clients 118 Configuring Option 184 parameters for DHCP clients 118 Customizing DHCP options 118 Configuring the DHCP user class whitelist 120 iii

9 Enabling DHCP 120 Enabling the DHCP server on an interface 121 Applying a DHCP address pool to a VPN instance 121 Applying an address pool on an interface 121 Configuring a DHCP policy for dynamic address assignment 122 Allocating different IP addresses to DHCP clients with the same MAC 123 Enabling random IP address allocation 123 Configuring IP address conflict detection 123 Enabling handling of Option Disabling Option 60 encapsulation in DHCP replies 124 Configuring the DHCP server security features 125 Restrictions and guidelines 125 Configuring DHCP flood attack protection 125 Configuring DHCP starvation attack protection 126 Configuring DHCP server compatibility 126 Configuring the DHCP server to always broadcast responses 126 Enabling the DHCP server to return a DHCP-NAK message upon client notions of incorrect IP addresses 127 Configure the DHCP server to ignore BOOTP requests 127 Configuring the DHCP server to send BOOTP responses in RFC 1048 format 128 Setting the DSCP value for DHCP packets sent by the DHCP server 128 Configuring DHCP packet rate limit on a DHCP server interface 128 Configuring DHCP binding auto backup 129 Binding gateways to DHCP server's MAC address 129 Advertising subnets assigned to clients 130 Enabling client offline detection on the DHCP server 131 Configuring SNMP notifications for the DHCP server 131 Enabling DHCP logging on the DHCP server 132 Display and maintenance commands for DHCP server 132 DHCP server configuration examples 133 Example: Configuring static IP address assignment 133 Example: Configuring dynamic IP address assignment 134 Example: Configuring DHCP user class 136 Example: Configuring DHCP user class whitelist 138 Example: Configuring primary and secondary subnets 139 Example: Customizing DHCP option 140 Example: Configuring DHCP server (WLAN application) 142 Network configuration 142 Procedure 143 Verifying the configuration 143 Troubleshooting DHCP server configuration 143 Failure to obtain a non-conflicting IP address 143 Configuring the DHCP relay agent 145 About DHCP relay agent 145 DHCP relay agent operation 145 DHCP relay agent support for Option DHCP relay agent support for MCE 146 DHCP relay agent tasks at a glance 147 Enabling DHCP 147 Enabling the DHCP relay agent on an interface 147 Specifying DHCP servers 148 Specifying DHCP servers on a relay agent 148 Configuring a DHCP address pool on a DHCP relay agent 148 Specifying the DHCP server selecting algorithm 149 Configuring the DHCP relay agent security features 151 Rustications and guidelines 151 Enabling the DHCP relay agent to record relay entries 151 Enabling periodic refresh of dynamic relay entries 151 Configuring DHCP flood attack protection 152 Enabling DHCP starvation attack protection 152 Enabling DHCP server proxy on the DHCP relay agent 153 iv

10 Enabling client offline detection on the DHCP relay agent 154 Configuring the DHCP relay agent to release an IP address 154 Configuring Option Setting the DSCP value for DHCP packets sent by the DHCP relay agent 155 Configuring DHCP packet rate limit on a DHCP relay interface 156 Specifying the DHCP relay agent address for the giaddr field 156 Manually specifying the DHCP relay agent address for the giaddr field 156 Configuring smart relay to specify the DHCP relay agent address for the giaddr field 156 Specifying the source IP address for DHCP requests 158 Configuring the DHCP relay agent to always unicast relayed DHCP responses 159 Configuring forwarding DHCP replies based on Option Display and maintenance commands for DHCP relay agent 160 DHCP relay agent configuration examples 161 Example: Configuring basic DHCP relay agent 161 Example: Configuring Option Example: Configuring DHCP server selection 162 Troubleshooting DHCP relay agent configuration 164 Failure of DHCP clients to obtain configuration parameters through the DHCP relay agent 164 Configuring the DHCP client 165 About DHCP client 165 Restrictions and guidelines: DHCP client configuration 165 Enabling the DHCP client on an interface 165 Configuring a DHCP client ID for an interface 165 Enabling duplicated address detection 166 Setting the DSCP value for DHCP packets sent by the DHCP client 166 Display and maintenance commands for DHCP client 167 DHCP client configuration examples 167 Example: Configuring DHCP client 167 Configuring DHCP snooping 170 About DHCP snooping 170 Application of trusted and untrusted ports 170 DHCP snooping support for Option Restrictions and guidelines: DHCP snooping configuration 172 DHCP snooping tasks at a glance 172 Configuring basic DHCP snooping 172 Configuring Option Configuring DHCP snooping entry auto backup 174 Enabling DHCP starvation attack protection 175 Enabling DHCP-REQUEST attack protection 175 Setting the maximum number of DHCP snooping entries 176 Configuring a DHCP packet blocking port 176 Enabling DHCP snooping logging 177 Display and maintenance commands for DHCP snooping 177 DHCP snooping configuration examples 178 Example: Configuring basic DHCP snooping 178 Example: Configuring DHCP snooping support for Option Configuring the BOOTP client 181 About BOOTP client 181 BOOTP application 181 Obtaining an IP address dynamically 181 Protocols and standards 181 Configuring an interface to use BOOTP for IP address acquisition 181 Display and maintenance commands for BOOTP client 182 BOOTP client configuration examples 182 Example: Configuring BOOTP client 182 DHCPv6 overview 183 DHCPv6 address/prefix assignment 183 Rapid assignment involving two messages 183 v

11 Assignment involving four messages 183 Address/prefix lease renewal 184 Stateless DHCPv6 185 DHCPv6 options 185 Option Option Protocols and standards 187 Configuring the DHCPv6 server 188 About DHCPv6 server 188 IPv6 address assignment 188 IPv6 prefix assignment 188 Concepts 189 DHCPv6 address pool 189 IPv6 address/prefix allocation sequence 190 DHCPv6 server tasks at a glance 191 Configuring IPv6 prefix assignment 191 Configuring IPv6 address assignment 193 Configuring network parameters assignment 194 Configuring network parameters in a DHCPv6 address pool 195 Configuring network parameters in a DHCPv6 option group 195 Configuring a DHCPv6 policy for IPv6 address and prefix assignment 196 Configuring the DHCPv6 server on an interface 197 Allocating different IPv6 addresses to DHCPv6 clients with the same MAC 198 Setting the DSCP value for DHCPv6 packets sent by the DHCPv6 server 198 Configuring DHCPv6 binding auto backup 199 Advertising subnets assigned to clients 199 Applying a DHCPv6 address pool to a VPN instance 200 Configuring the DHCPv6 server security features 201 Configuring DHCPv6 flood attack protection 201 Enabling the DHCPv6 server to advertise IPv6 prefixes 202 Enabling DHCPv6 logging on the DHCPv6 server 202 Display and maintenance commands for DHCPv6 server 202 DHCPv6 server configuration examples 203 Example: Configuring dynamic IPv6 prefix assignment 203 Example: Configuring dynamic IPv6 address assignment 206 Configuring the DHCPv6 relay agent 208 About DHCPv6 relay agent 208 Typical application 208 DHCPv6 relay agent operating process 208 DHCPv6 relay agent tasks at a glance 209 Enabling the DHCPv6 relay agent on an interface 209 Specifying DHCPv6 servers on the relay agent 209 Specifying the DHCPv6 server IP addresses 209 Specifying DHCPv6 servers for a DHCPv6 address pool on the DHCPv6 relay agent 210 Specifying a gateway address for DHCPv6 clients 211 Setting the DSCP value for DHCPv6 packets sent by the DHCPv6 relay agent 211 Specifying a padding mode for the Interface-ID option 212 Configuring DHCPv6 relay security features 212 Enabling the DHCPv6 relay agent to record relay entries 212 Enabling IPv6 release notification 212 Enabling client offline detection 213 Configuring DHCPv6 flood attack protection 213 Enabling the DHCPv6 relay agent to advertise IPv6 prefixes 214 Display and maintenance commands for DHCPv6 relay agent 214 DHCPv6 relay agent configuration examples 215 Example: Configuring DHCPv6 relay agent 215 Configuring DHCPv6 snooping 217 About DHCPv6 snooping 217 Application of trusted and untrusted ports 217 vi

12 Restrictions and guidelines: DHCPv6 snooping configuration 218 DHCPv6 snooping tasks at a glance 218 Configuring basic DHCPv6 snooping 218 Configuring support for Option Configuring support for Option Configuring DHCPv6 snooping entry auto backup 219 Setting the maximum number of DHCPv6 snooping entries 220 Enabling DHCPv6-REQUEST check 220 Configuring a DHCPv6 packet blocking port 221 Enabling DHCPv6 snooping logging 221 Display and maintenance commands for DHCPv6 snooping 222 Example: Configuring DHCPv6 snooping 222 Network configuration 222 Procedure 223 Verifying the configuration 223 Configuring ITA 224 About ITA 224 Restrictions: Hardware compatibility with ITA 224 Restrictions and guidelines: ITA configuration 224 ITA tasks at a glance 224 Configuring an ITA policy 225 Display and maintenance commands for ITA 226 ITA configuration examples 226 Example: Configuring ITA for IPoE users 226 Configuring user profiles 230 About user profiles 230 Prerequisites 230 Restrictions and guidelines: User profile configuration 230 Configuring a user profile for a single user 230 Configuring a user profile for a user group 231 Display and maintenance commands for user profiles 232 Configuring connection limits (interface-based) 233 About connection limits 233 Restrictions: Hardware compatibility with connection limits configuration 233 Connection limit tasks at a glance 233 Creating a connection limit policy 233 Configuring the connection limit policy 234 About connection limit policies 234 Restrictions and guidelines for connection limit policy configuration 234 Configuring an IPv4 connection limit policy 234 Configuring an IPv6 connection limit policy 235 Applying the connection limit policy 235 Display and maintenance commands for connection limits 236 Troubleshooting connection limits 236 ACLs in the connection limit rules with overlapping segments 236 Configuring connection limits (user profile-based) 238 About connection limits 238 Restrictions: Hardware compatibility with connection limits configuration 238 Prerequisites for connection limits 238 Configuring connection limits 239 Connection limit configuration examples 239 Example: Configuring connection limits 239 Configuring L2TP 241 About L2TP 241 Typical L2TP networking 241 L2TP message types and encapsulation structure 241 L2TP tunnel and session 242 vii

13 L2TP tunneling modes and tunnel establishment process 242 L2TP features 245 L2TP-based EAD 247 Protocols and standards 247 Restrictions: Hardware compatibility with L2TP 247 Restrictions and guidelines: L2TP configuration 247 L2TP tasks at a glance 248 Configuring basic L2TP capabilities 249 Configuring an LAC 249 Configuring an LAC to initiate tunneling requests for a user 249 Specifying LNS IP addresses 250 Configuring the source IP address of L2TP tunnel packets 250 Configuring each L2TP user to use an L2TP tunnel exclusively 250 Enabling transferring AVP data in hidden mode 251 Configuring AAA authentication on an LAC 251 Configuring an LAC to automatically establish an L2TP tunnel 251 Configuring an LNS 253 Creating a VT interface 253 Configuring an LNS to accept L2TP tunneling requests from an LAC 253 Configuring user authentication on an LNS 253 Configuring AAA authentication on an LNS 255 Setting the maximum number of ICRQ packets that the LNS can process per second 255 Configuring optional L2TP parameters 255 Configuring L2TP tunnel authentication 255 Setting the Hello interval 256 Setting the DSCP value of L2TP packets 256 Setting the TSA ID of the LTS 257 Enabling L2TP-based EAD 257 Configuring IMSI/SN binding authentication on the LNS 258 Display and maintenance commands for L2TP 258 L2TP configuration examples 259 Example: Configuring a NAS-initiated L2TP tunnel 259 Example: Configuring a client-initiated L2TP tunnel 261 Example: Configuring an LAC-auto-initiated L2TP tunnel 262 Troubleshooting L2TP 265 Failure to access the private network 265 Data transmission failure 265 L2TP user offline 265 Configuring PPPoE 267 About PPPoE 267 PPPoE network structure 267 Router-initiated network structure 267 Host-initiated network structure 268 Protocols and standards 268 Restrictions: Hardware compatibility with IPoE 268 Restrictions and guidelines: PPPoE configuration 268 Configuring the PPPoE server 269 PPPoE server tasks at a glance 269 Configuring a PPPoE session 269 Setting the maximum number of PPPoE sessions 270 Limiting the PPPoE access rate 270 Configuring the NAS-Port-ID attribute 271 Enabling PPPoE users to come online despite the PPPoE-NAT444 collaboration failure 272 Setting the maximum number of PADI packets that the device can receive per second 273 Configuring PPPoE user blocking 273 Enabling PPPoE logging 274 Display and maintenance commands for PPPoE 274 PPPoE configuration examples 275 Example: Configuring the PPPoE server 275 Example: Assigning the PPPoE server IP address through the local DHCP server 276 Example: Assigning the PPPoE server IP address through a remote DHCP server 277 viii

14 Example: Assigning the PPPoE server IPv6 address through ND and IPv6CP negotiation 279 Example: Assigning the PPPoE server IPv6 address through DHCPv6 281 Example: Assigning the PPPoE server IPv6 address through prefix delegation by DHCPv6 282 Example: Configuring PPPoE server RADIUS-based IP address assignment 283 Configuring portal authentication 286 About portal 286 Advantages of portal authentication 286 Extended portal functions 286 Portal system 286 Portal authentication using a remote portal server 287 Local portal service 288 Portal authentication modes 288 Portal authentication process 289 Portal filtering rules 291 MAC-based quick portal authentication 291 Restrictions: Hardware compatibility with portal 292 Restrictions and guidelines: Portal configuration 292 Portal tasks at a glance 292 Prerequisites for portal 294 Configuring a portal authentication server 294 Configuring a portal Web server 295 Configure basic parameters for a portal Web server 295 Configuring a match rule for URL redirection 296 Configuring a local portal Web service 296 Restrictions and guidelines for configuring a local portal Web service 296 Customizing authentication pages 296 Configuring parameters for a local portal Web service 298 Specifying a portal authentication domain 299 About portal authentication domains 299 Restrictions and guidelines for specifying a portal authentication domain 299 Specifying a portal authentication domain on an interface 300 Configuring a portal preauthentication policy 300 About portal preauthentication policies 300 Restrictions and guidelines 300 Procedure 300 Specifying a preauthentication IP address pool 301 About preauthentication IP address pools 301 Restrictions and guidelines 301 Procedure 302 Enabling portal authentication on an interface 302 Restrictions and guidelines 302 Procedure 303 Specifying a portal Web server on an interface 303 Controlling portal user access 304 Configuring a portal-free rule 304 Configuring an authentication source subnet 305 Setting the maximum number of portal users 306 Enabling strict-checking on portal authorization information 307 Allowing only users with DHCP-assigned IP addresses to pass portal authentication 308 Configuring support of Web proxy for portal authentication 308 Blocking portal users that fail portal authentication 309 Enabling portal roaming 309 Configuring the portal fail-permit feature 310 Configuring portal detection features 311 Configuring online detection of portal users 311 Configuring portal authentication server detection 312 Configuring portal Web server detection 313 Configuring portal user synchronization 313 Configuring portal packet attributes 314 Configuring the BAS-IP or BAS-IPv6 attribute 314 Specifying the device ID 315 ix

15 Configuring attributes for RADIUS packets 316 Specifying a format for the NAS-Port-Id attribute 316 Applying a NAS-ID profile to an interface 316 Configuring MAC-based quick portal authentication 317 Restrictions and guidelines for configuring MAC-based quick portal authentication 317 Configuring a MAC binding server 317 Specifying a MAC binding server on an interface 318 Configuring portal HTTP attack defense 318 Setting the user traffic backup threshold 319 Logging out online portal users 319 Enabling portal user login/logout logging 320 Configuring Web redirect 320 About Web redirect 320 Restrictions and guidelines 320 Procedure 320 Display and maintenance commands for portal 321 Portal configuration examples 322 Example: Configuring direct portal authentication 322 Example: Configuring re-dhcp portal authentication 330 Example: Configuring cross-subnet portal authentication 334 Example: Configuring extended direct portal authentication 337 Example: Configuring extended re-dhcp portal authentication 341 Example: Configuring extended cross-subnet portal authentication 345 Example: Configuring portal server detection and portal user synchronization 348 Example: Configuring cross-subnet portal authentication for MPLS L3VPNs 356 Example: Configuring direct portal authentication with a preauthentication policy 358 Example: Configuring re-dhcp portal authentication with a preauthentication policy 360 Example: Configuring direct portal authentication using a local portal Web service 362 Example: Configuring MAC-based quick portal authentication 365 Troubleshooting portal 373 No portal authentication page is pushed for users 373 Cannot log out portal users on the access device 374 Cannot log out portal users on the RADIUS server 374 Users logged out by the access device still exist on the portal authentication server 374 Re-DHCP portal authenticated users cannot log in successfully 375 Configuring IPoE 376 About IPoE 376 IPoE access modes 376 IPoE users 376 IPoE session 377 IPoE addressing 378 IPoE authentication methods 378 IPoE access procedure by using bind authentication 378 Support for MPLS L3VPN 381 Support for ITA 382 Restrictions: Hardware compatibility with IPoE 382 Restrictions and guidelines: IPoE configuration 382 IPoE tasks at a glance 382 Prerequisites for IPoE 383 Enabling IPoE and setting the IPoE access mode 383 Configuring bind authentication 383 Configuring dynamic individual users 384 Dynamic individual user configuration tasks at a glance 384 Enabling dynamic individual users 384 Configuring authentication user naming conventions for dynamic individual users 385 Configuring passwords for dynamic individual users 388 Configuring ISP domains for dynamic individual users 388 Configuring the maximum number of dynamic IPoE sessions 389 Configuring trusted DHCP options for DHCP users 390 Configuring trusted ISP domains for DHCP users 390 Configuring trusted source IP addresses for unclassified-ip users 391 x

16 Enabling dynamic individual users to come online despite the IPoE-NAT collaboration failure 392 Configuring static individual users 392 Static individual user configuration tasks at a glance 392 Enabling static individual users 392 Configuring static IPoE sessions on an interface 393 Configuring global static IPoE sessions 394 Configuring authentication user naming conventions for static individual users 394 Configuring passwords for static individual users 395 Configuring ISP domains for static individual users 396 Configuring leased users 396 Leased user configuration tasks at a glance 396 Configuring interface-leased users 397 Configuring subnet-leased users 397 Configuring L2VPN-leased users 398 Configuring ISP domains for leased users 398 Configuring service-specific ISP domains 399 Configuring the quiet feature for users 400 Configuring online detection for users 400 Configuring NAS-Port-Type for an interface 401 Configuring NAS-Port-ID formats 402 Enabling IPoE access-out authentication 402 Setting the traffic statistics update timer for IPoE sessions 403 Enabling logging for IPoE users 403 Display and maintenance commands for IPoE 404 IPoE configuration examples 408 Example: Configuring an unclassified-ip user 408 Example: Configuring a DHCP user 410 Example: Configuring an IPv6-ND-RS user 412 Example: Configuring an ARP-based static user 413 Example: Configuring subnet-leased users 415 Example: Configuring an interface-leased user 419 Example: Configuring an L2VPN-leased user 421 Example: Configuring a VPN DHCP user 425 Example: Configuring online detection 428 Troubleshooting IPoE 430 DHCP clients failed to come online 430 Index 431 xi

17 BRAS services overview A broadband remote access server (BRAS) is an access gateway for broadband network applications. It provides a basic access approach to the backbone network and management features for the broadband access network. BRAS network Figure 1 describes the location of the BRAS device in the ISP network. Figure 1 BRAS device in the ISP network Internet ISP Source RADIUS server Router C DHCP server IRF BRAS Router A BRAS Router B Layer 3 switch (OLT) Domestic user POS Enterprise user Layer 2 switch VLAN 10 ONU1 ONU2... ONUn 1

18 BRAS components Figure 2 BRAS components AAA management AAA User access Address assignment DHCP Service management ITA Figure 3 Introduction to BRAS components BRAS services User access This component provides the following services: Portal Portal authentication, also referred to as Web authentication, controls user access to networks. Portal authenticates a user by the username and password the user enters on a portal authentication page. Portal authentication provides a flexible access control method without the installation of client software. It is deployed on the access layer and vital data entries. 2

19 An unauthenticated user is required to visit a specific authentication website with free access to services on that page. To access other network resources, the user has to perform authentication on the authentication website. Users that pass portal authentication are allowed to access authorized network resources. For more information, see portal configuration in BRAS Services Configuration Guide. IPoE IP over Ethernet (IPoE) is a IPoX access method. In IPoE, a BRAS receives IP packets from Ethernet users and authenticates users based on their access location or packet characteristics. The AAA server authorizes users that pass authentication with corresponding access rights. For more information, see IPoE configuration in BRAS Services Configuration Guide. PPPoE Point-to-Point Protocol over Ethernet (PPPoE) extends PPP by transporting PPP frames encapsulated in Ethernet over point-to-point links. PPPoE provides Internet access for the hosts in an Ethernet through a remote access device and implements access control, authentication, and accounting on a per-host basis. Integrating the low cost of Ethernet and scalability and management functions of PPP, PPPoE gained popularity in various application environments, such as residential access networks. For more information, see PPPoE configuration in BRAS Services Configuration Guide. L2TP The Layer 2 Tunneling Protocol (L2TP) is a Virtual Private Dialup Network (VPDN) tunneling protocol. L2TP sets up point-to-point tunnels across a public network (for example, the Internet) and transmits encapsulated PPP frames (L2TP packets) over the tunnels. With L2TP, remote users can access the private networks through L2TP tunnels after connecting to a public network by using PPP. For more information, see L2TP configuration in BRAS Services Configuration Guide. AAA management 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 has various implementations, including RADIUS, HWTACACS, and LDAP. RADIUS is most often used. For more information, see AAA configuration in BRAS Services Configuration Guide. Address assignment This component provides the following address assignment methods: Static address For more information about configuring a static IPv4 address and a static IPv6 address, see IP addressing configuration and IPv6 basics configuration in Layer 3 IP Services Configuration Guide. DHCP The Dynamic Host Configuration Protocol (DHCP) provides a framework to assign configuration information to network devices. For more information, see DHCP configuration in BRAS Services Configuration Guide. DHCPv6 DHCPv6 provides a framework to assign IPv6 prefixes, IPv6 addresses, and other configuration parameters to hosts. For more information, see DHCPv6 configuration in BRAS Services Configuration Guide. Stateless address autoconfiguration A node automatically generate an IPv6 global unicast address based on the address prefix information contained in the RA message. For more information, see IPv6 basics configuration in Layer 3 IP Services Configuration Guide. Service management The device provides various service management functions and service support for users. 3

20 Table 1 Managing access services Service name Authorization ACL Authorization CAR action Authorization user group Traffic permission Online detection Multicast access control ANCP User profile Connection limit Introduction You can configure this attribute for the ISP domain to restrict authenticated users to access only the network resources permitted by the ACL. You can configure this attribute for the ISP domain to control the traffic flow of authenticated users. You can specify the user group for authenticated users when you configure authorization attributes for the ISP domain. Traffic permission allows matching traffic to pass through without performing rate limiting and accounting on the traffic. Online detection enables the BRAS to periodically detect the status of a user. Online detection for PPPoE users is enabled by default. When the user requests to join a multicast group, you can use this feature to control user access by refusing illegal or unauthorized requests. Access Node Control Protocol (ANCP) exchanges control messages between a Broadband Remote Access Server (BRAS) and an Access Node (AN). A user profile is a configuration template that defines a set of parameters. The user can configure different parameters according to different scenarios. This feature enables the device to control the number of established connections, the establishment rate, and the bandwidth consumption. It protects network resources and facilitates accurate allocation of system resources. Reference AAA configuration in BRAS Services Configuration Guide AAA configuration in BRAS Services Configuration Guide AAA configuration in BRAS Services Configuration Guide Traffic policing, GTS, and rate limit configuration in ACL and QoS Configuration Guide IPoE configuration and portal configuration in AAA configuration in BRAS Services Configuration Guide IGMP configuration and MLD configuration in IP Multicast Configuration Guide "Configuring ANCP" "Configuring user profiles" "Configuring connection limits" Table 2 Managing value-added services Service name ITA Introduction Intelligent Target Accounting (ITA) provides a flexible accounting solution for users who request services of different charge rates. By defining different traffic levels based on the destination addresses of users' traffic, you can use ITA to separate the traffic accounting statistics of different levels for each user. Reference "Configuring ITA" 4

21 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 4. Figure 4 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 RADIUS, HWTACACS, and LDAP. 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. 5

22 RADIUS The device performs dynamic password authentication. 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 5 RADIUS server databases 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. 6

23 User authentication methods The RADIUS server supports multiple user authentication methods, such as PAP, CHAP, and EAP. Basic RADIUS packet exchange process Figure 6 illustrates the interactions between a user host, the RADIUS client, and the RADIUS server. Figure 6 Basic RADIUS packet exchange process 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. 7

24 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 7 RADIUS packet format Descriptions of the fields are as follows: The Code field (1 byte long) indicates the type of the RADIUS packet. Table 3 gives the main values and their meanings. Table 3 Main values of the Code field Code Packet type Description 1 Access-Request 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 User-Name attribute and can optionally contain the attributes of NAS-IP-Address, User-Password, and NAS-Port. 2 Access-Accept 3 Access-Reject From the server to the client. If all attribute values included in the 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 Access-Request is unacceptable, the authentication fails, and the server sends an Access-Reject response. 4 5 Accounting-Reques t Accounting-Respon se From the client to the server. A packet of this type includes user information for the server to start or stop accounting for the user. The 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 notify the client that it has received the Accounting-Request and has 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. 8

25 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 8, 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 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 For more information, see "Appendix C RADIUS subattributes (vendor ID 25506)." Figure 8 Format of attribute 26 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 4 lists the primary differences between HWTACACS and RADIUS. Table 4 Primary differences between HWTACACS and RADIUS HWTACACS Uses TCP, which provides reliable network transmission. RADIUS Uses UDP, which provides high transport efficiency. 9

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

27 Figure 9 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) Continue-authentication packet with the username 7) Authentication response requesting the password 8) Request for password 9) The user enters the password 10) Continue-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. 11

28 LDAP 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. 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, s, 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: 12

29 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 10 Basic LDAP authentication process for a Telnet user 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. 13

30 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 11. 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 11 Basic LDAP authorization process for a Telnet user 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 10. 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 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. 14

31 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 12 Determining the ISP domain for a user by username 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 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 or AUX port. Portal Portal users must pass portal authentication to access the network. PPP. IPoE IPoE users include Layer 2 and Layer 3 leased line users and Set Top Box (STB) users. NOTE: The device also provides authentication modules 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. 15

32 AAA also supports configuring a set of default methods for an ISP domain. These default methods are applied to users for which no AAA methods are configured. Authentication methods The device supports the following authentication methods: 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 RADIUS, HWTACACS, or LDAP server to authenticate users. 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: Non-login users can access the network. 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. Local authorization The NAS performs authorization according to the user attributes locally configured for users. Remote authorization The NAS works with a RADIUS, HWTACACS, or LDAP 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 authorization is separate from HWTACACS 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. 16

33 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. 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 MPLS L3VPNs You can deploy AAA across VPNs in an MPLS L3VPN scenario where clients in different VPNs are centrally authenticated. The deployment enables forwarding of RADIUS and HWTACACS packets across MPLS VPNs. For example, as shown in Figure 13, you can deploy AAA across the VPNs. The PE 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 13 Network diagram This feature can also help an MCE to implement portal authentication for VPNs. For more information about MCE, see MPLS Configuration Guide. For more information about portal authentication, see "Configuring portal authentication." 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 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 17

34 RFC 2251, Lightweight Directory Access Protocol (v3) AAA tasks at a glance To configure AAA, complete the following tasks on the NAS: 1. Configure the required AAA schemes: If local authentication is used, configure local users and the related attributes. If remote authentication is used, configure the required RADIUS, HWTACACS, or LDAP schemes. 2. Configure AAA methods for the users' ISP domains, including none, local, scheme, or any combination of them. Figure 14 AAA configuration procedure Local AAA Configure local users and related attributes Configure AAA methods for different types of users or/and the default methods for all types of users Authentication method none/ local (the default)/scheme No AAA Create an ISP domain and enter ISP domain view + Authorization method none/ local (the default)/scheme + Configure the RADIUS, HWTACACS, or LDAP schemes to be used Accounting method none/ local (the default)/scheme Remote AAA To configure AAA, perform the following tasks: Tasks at a glance (Required.) Perform a minimum one of the following tasks to configure local users or AAA schemes: Configuring local users Configuring RADIUS Configuring HWTACACS Configuring LDAP (Required.) Configure AAA methods for ISP domains: 1. (Required.) Creating an ISP domain 2. (Optional.) Configuring ISP domain attributes 3. (Required.) Perform a minimum one of the following tasks to configure AAA authentication, authorization, and accounting methods for the ISP domain: Configuring authentication methods for an ISP domain Configuring authorization methods for an ISP domain Configuring accounting methods for an ISP domain (Optional.) Setting the maximum number of concurrent login users (Optional.) Configuring the local bill cache feature (Optional.) Configuring a NAS-ID 18

35 Tasks at a glance (Optional.) Configuring the device ID 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. Network access users also include guests that access the network temporarily. Guests can use only LAN and portal services. The following shows the configurable local user attributes: 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. For example, you do not need to configure the FTP/SFTP/SCP working directory attribute for a PPP user. 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 device management 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 Security Configuration Guide. 19

36 Local user configuration tasks at a glance Tasks at a glance (Required.) Configure local user attributes based on the user type: Configuring attributes for device management users Configuring attributes for network access users Configuring local guest attributes (Optional.) Configuring user group attributes (Optional.) Managing local guests Configuring attributes for device management users When you configure attributes for a device management user, follow these restrictions and guidelines: When you use the password-control enable command to globally enable the password control feature, local user passwords are not displayed. 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. To configure attributes for a device management user: 2. Add a local user and enter device management user view. local-user user-name [ class manage ] By default, no local users exist. 3. (Optional.) Configure a password for the local user. 4. Assign services to the local user. 5. (Optional.) Set the status of the local user. 6. (Optional.) Set the upper limit of concurrent logins using the local user name. password [ { hash simple } string ] service-type { ftp ssh telnet terminal } * } state { active block } access-limit max-user-number By default, no password is configured for a local user. A local user can pass authentication after entering the correct username and passing attribute checks. By default, no services are authorized to a local user. By default, a local user is in active state and can request network services. By default, the number of concurrent logins is not limited for the local user. This command takes effect only when local accounting is configured for the local user. It does not apply to FTP, SFTP, or SCP users. These users do not support accounting. 20

37 7. (Optional.) Configure authorization attributes for the local user. 8. (Optional.) Configure password control attributes for the local user. 9. (Optional.) Assign the local user to a user group. authorization-attribute { idle-cut minutes user-role role-name work-directory directory-name } * 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 } ] group group-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. By default, the local user uses password control attributes of the user group to which the local user belongs. By default, a local user belongs to the user group system. Configuring attributes for network access users When you configure attributes for a network access user, follow these restrictions and guidelines: You can configure authorization 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. For MAC authentication users, specify the MAC 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 configured. To configure attributes for a network access user: 21

38 2. Add a local user and enter network access user view. 3. (Optional.) Configure a password for the local user. 4. Assign services to the local user. 5. (Optional.) Set the status of the local user. 6. (Optional.) Set the upper limit of concurrent logins using the local user name. 7. (Optional.) Configure binding attributes for the local user. 8. (Optional.) Configure authorization attributes for the local user. 9. (Optional.) Assign the local user to a user group. local-user user-name [ class network ] password { cipher simple } string service-type { ipoe lan-access portal ppp } state { active block } access-limit max-user-number bind-attribute { call-number call-number [ : subcall-number ] location interface interface-type interface-number mac mac-address vlan vlan-id } * authorization-attribute { acl acl-number callback-number callback-number idle-cut minutes ip ipv4-address ip-pool ipv4-pool-name ipv6 ipv6-address ipv6-pool ipv6-pool-name ipv6-prefix ipv6-prefix prefix-length { primary-dns secondary-dns } { ip ipv4-address ipv6 ipv6-address } session-group-profile session-group-profile-name session-timeout minutes subscriber-id subscriber-id url url-string user-profile user-profile-name vlan vlan-id vpn-instance vpn-instance-name } * group group-name By default, no local users exist. By default, no password is configured for a local user. A local user can pass authentication after entering the correct username and passing attribute checks. By default, no services are authorized to a local user. The ipoe and portal keywords take effect only on CSPEX cards. By default, a local user is in active state and can request network services. By default, the number of concurrent logins is not limited for the local user. This command takes effect only when local accounting is configured for the local user. By default, no binding attributes are configured for a local user. By default, no authorization attribute exists for a network access user. The user-profile user-profile-name option takes effect only on CSPEX cards. By default, a local user belongs to the user group system. Configuring local guest attributes Create local guests and configure guest attributes to control temporary network access behavior. Guests can access the network after passing local authentication. You can configure the recipient addresses and attribute information to the local guests and guest sponsors. 22

39 To configure local guest attributes: 2. Create a local guest and enter local guest view. 3. Configure a password for the local guest. 4. Configure a description for the local guest. 5. Specify the name of the local guest. 6. Specify the company of the local guest. 7. Specify the phone number of the local guest. 8. Specify the address of the local guest. 9. Specify the sponsor name for the local guest. 10. Specify the sponsor department for the local guest. 11. Specify the sponsor address for the local guest. 12. Configure the validity period for the local guest. 13. Assign the local guest to a user group. 14. Configure the local guest status. local-user user-name class network guest password { cipher simple } string description text full-name name-string company company-name phone phone-number -string sponsor-full-name name-string sponsor-department department-string sponsor- -string validity-datetime start-date start-time to expiration-date expiration-time group group-name state { active block } By default, no local guests exist. By default, no password is configured for a local guest. By default, no description is configured for a local guest. By default, no name is specified for a local guest. By default, no company is specified for a local guest. By default, no phone number is specified for a local guest. By default, no address is specified for a local guest. The device sends notifications to this address to inform the guest of the account information. By default, no sponsor name is specified for a local guest. By default, no sponsor department is specified for a local guest. By default, no sponsor address is specified for a local guest. The device sends notifications to this address to inform the sponsor of the guest information. By default, a local guest does not expire. Expired guests cannot pass local authentication. By default, a local guest belongs to the system-defined user group system. By default, a local guest is in active state and is allowed to request network services. Configuring user group attributes 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. 23

40 By default, every new local user belongs to the default user group system and has all attributes of the group. To assign a local user to a different user group, use the group command in local user view. To configure user group attributes: 2. Create a user group and enter user group view. 3. Configure authorization attributes for the user group. 4. (Optional.) Configure password control attributes for the user group. user-group group-name authorization-attribute { acl acl-number callback-number callback-number idle-cut minutes ip-pool ipv4-pool-name ipv6-pool ipv6-pool-name ipv6-prefix ipv6-prefix prefix-length { primary-dns secondary-dns } { ip ipv4-address ipv6 ipv6-address } session-group-profile session-group-profile-name session-timeout minutes subscriber-id subscriber-id url url-string user-profile user-profile-name vlan vlan-id vpn-instance vpn-instance-name work-directory directory-name } * 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 system-defined user group exists. The group name is system. By default, no authorization attributes are configured for a user group. The user-profile user-profile-name option takes effect only on CSPEX cards. By default, the user group uses the global password control settings. For more information, see Security Configuration Guide. 24

41 Managing local guests About local guest management The local guest management features are for registration, approval, maintenance, and access control of local guests. The registration and approval processes are as follows: 1. The device pushes the portal user registration page to a user that wants to access the network as a local guest. 2. The user submits account information for registration, including the user name, password, and address. 3. The device forwards the registration request to the guest manager in an notification. 4. The guest manager adds supplementary information as needed and approves the registration information. The guest manager must process the registration request before the waiting-approval timeout timer expires. The device automatically deletes expired registration request information. 5. The device creates a local guest account and sends an notification to the user and guest sponsor. The contains local guest account, password, validity period, and other account information. The user can access the network as a local guest. The device provides the following local guest management features: Registration and approval The device creates local guests after the guest registration information is approved by a guest manager. notification The device notifies the local guests, guest sponsors, or guest managers by of the guest account information or guest registration requests. Local guest creation in batch Create a batch of local guests. Local guest import Import guest account information from a.csv file to create local guests on the device based on the imported information. Local guest export Export local guest account information to a.csv file. You can import the account information to other devices as needed. Guest auto-delete The device regularly checks the validity status of each local guest and automatically deletes expired local guests. Procedure To manage local guests: 1. Enter system view system-view N/A 2. Configure the subject and body of notifications. 3. Configure the sender address in the notifications sent by the device for local guests. 4. Specify an SMTP server for sending notifications of local guests. local-guest format to { guest manager sponsor } { body body-string subject sub-string } local-guest sender -address local-guest smtp-server url-string By default, no subject and body are configured. By default, no sender address is configured for the notifications sent by the device. By default, no SMTP server is specified. 25

42 5. Configure the guest manager's address. 6. (Optional.) Set the waiting-approval timeout timer for guest registration requests. local-guest manager- -address local-guest timer waiting-approval time-value By default, the guest manager's address is not configured. The default is 24 hours. 7. (Optional.) Import guest account information from a.csv file in the specified path to create local guests based on the imported information. 8. (Optional.) Create local guests in batch. 9. (Optional.) Export local guest account information to a.csv file in the specified path. 10. (Optional.) Enable the guest auto-delete feature. local-user-import class network guest url url-string validity-datetime start-date start-time to expiration-date expiration-time [ auto-create-group override start-line line-number ] * local-guest generate username-prefix name-prefix [ password-prefix password-prefix ] suffix suffix-number [ group group-name ] count user-count validity-datetime start-date start-time to expiration-date expiration-time local-user-export class network guest url url-string local-guest auto-delete enable N/A Batch generated local guests share the same name prefix. You can also configure a password prefix to be shared by the guests. N/A By default, the guest auto-delete feature is disabled. 11. Return to user view. quit N/A 12. Send notifications to the local guest or the guest sponsor. local-guest send- user-name user-name to { guest sponsor } The contents include the user name, password, and validity period of the guest account. Display and maintenance commands for local users and local user groups Execute display commands in any view and reset commands in user view. Task Display the local user configuration and online user statistics. Display the user group configuration. Display pending registration requests for local guests. Clear pending registration requests for local guests. Command display local-user [ class { manage network [ guest ] } idle-cut { disable enable } service-type { ftp ipoe lan-access portal ppp ssh telnet terminal } state { active block } user-name user-name class { manage network [ guest ] } vlan vlan-id ] display user-group { all name group-name } display local-guest waiting-approval [ user-name user-name ] reset local-guest waiting-approval [ user-name user-name ] 26

43 Configuring RADIUS RADIUS tasks at a glance Tasks at a glance (Optional.) Configuring a test profile for RADIUS server status detection (Required.) Creating a RADIUS scheme (Required.) Specifying the RADIUS authentication servers (Optional.) Specifying the RADIUS accounting servers (Optional.) Specifying the shared keys for secure RADIUS communication (Optional.) Specifying an MPLS L3VPN instance for the scheme (Optional.) Setting the username format and traffic statistics units (Optional.) Setting the maximum number of RADIUS request transmission attempts (Optional.) Setting the maximum number of real-time accounting attempts (Optional.) Configuring RADIUS stop-accounting packet buffering (Optional.) Setting the maximum number of pending RADIUS requests (Optional.) Setting the status of RADIUS servers (Optional.) Enabling the RADIUS server load sharing feature (Optional.) Specifying the source IP address for outgoing RADIUS packets (Optional.) Setting RADIUS timers (Optional.) Configuring the RADIUS accounting-on feature (Optional.) Interpreting the RADIUS class attribute as CAR parameters (Optional.) Configuring the Login-Service attribute check method for SSH, FTP, and terminal users (Optional.) Configuring the MAC address format for RADIUS attribute 31 (Optional.) Configuring the format for RADIUS attribute 87 (Optional.) Setting the data measurement unit for the Remanent_Volume attribute (Optional.) Specifying a server version for interoperating with servers with a vendor ID of 2011 (Optional.) Configuring the RADIUS attribute translation feature (Optional.) Configuring the RADIUS session-control feature (Optional.) Configuring the RADIUS DAS feature (Optional.) Changing the DSCP priority for RADIUS packets (Optional.) Configuring the device to preferentially process RADIUS authentication requests (Optional.) Enabling SNMP notifications for RADIUS Configuring a test profile for RADIUS server status detection Use a test profile to detect whether a RADIUS authentication server is reachable at a detection interval. To detect the RADIUS server status, you must configure the RADIUS server to use this test profile in a RADIUS scheme. 27

44 With the test profile specified, the device sends a detection packet to the RADIUS server within each detection interval. The detection packet is a simulated authentication request that includes the specified user name in the test profile. If the device receives a response from the server within the interval, it sets the server to the active state. If the device does not receive any response from the server within the interval, it sets the server to the blocked state. The device refreshes the RADIUS server status at each detection interval according to the detection result. The device stops detecting the status of the RADIUS server when one of the following operations is performed: The RADIUS server is removed from the RADIUS scheme. The test profile configuration is removed for the RADIUS server in RADIUS scheme view. The test profile is deleted. The RADIUS server is manually set to the blocked state. The RADIUS scheme is deleted. To configure a test profile for RADIUS server status detection: 2. Configure a test profile for detecting the status of RADIUS authentication servers. radius-server test-profile profile-name username name [ interval interval ] By default, no test profiles exist. You can configure multiple test profiles in the system. Creating a RADIUS scheme Create a RADIUS scheme before performing any other RADIUS configurations. You can configure a maximum of 16 RADIUS schemes. A RADIUS scheme can be used by multiple ISP domains. To create a RADIUS scheme: 2. Create a RADIUS scheme and enter RADIUS scheme view. radius scheme radius-scheme-name By default, no RADIUS schemes exist. Specifying the RADIUS authentication servers 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 unavailable. The device searches for an active server in the order the secondary servers are configured. 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. 28

45 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. To specify RADIUS authentication servers for a RADIUS scheme: 2. Enter RADIUS scheme view. radius scheme radius-scheme-name N/A 3. Specify RADIUS authentication servers. Specify the primary RADIUS authentication server: primary authentication { ipv4-address ipv6 ipv6-address } [ port-number key { cipher simple } string test-profile profile-name vpn-instance vpn-instance-name weight weight-value ] * Specify a secondary RADIUS authentication server: secondary authentication { 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 authentication servers are specified. To support server status detection, specify an existing test profile for the RADIUS authentication server. If the test profile does not exist, the device cannot detect the server status. Two authentication servers in a scheme, primary or secondary, cannot have the same combination of IP address, port number, and VPN instance. The weight weight-value option takes effect only when the RADIUS server load sharing feature is enabled for the RADIUS scheme. Specifying the RADIUS accounting servers 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. 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. 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. RADIUS does not support accounting for FTP, SFTP, and SCP users. To specify RADIUS accounting servers for a RADIUS scheme: 2. Enter RADIUS scheme view. radius scheme radius-scheme-name N/A 29

46 3. Specify RADIUS accounting servers. Specify the primary RADIUS accounting server: primary accounting { ipv4-address ipv6 ipv6-address } [ port-number key { cipher simple } string vpn-instance vpn-instance-name weight weight-value ] * Specify a secondary RADIUS accounting server: secondary accounting { ipv4-address ipv6 ipv6-address } [ port-number key { cipher simple } string vpn-instance vpn-instance-name weight weight-value ] * By default, no accounting servers are specified. Two accounting servers in a scheme, primary or secondary, cannot have the same combination of IP address, port number, and VPN instance. The weight weight-value option takes effect only when the RADIUS server load sharing feature is enabled for the RADIUS scheme. Specifying the shared keys for secure RADIUS communication 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. To specify a shared key for secure RADIUS communication: 2. Enter RADIUS scheme view. 3. Specify a shared key for secure RADIUS communication. radius scheme radius-scheme-name key { accounting authentication } { cipher simple } string N/A By default, no shared key is specified for secure RADIUS communication. The shared key configured on the device must be the same as the shared key configured on the RADIUS server. Specifying an MPLS L3VPN instance for the scheme 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. To specify a VPN instance for a scheme: 2. Enter RADIUS scheme view. radius scheme radius-scheme-name 30 N/A

47 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 username format and traffic statistics units A username is in the userid@isp-name format, where the isp-name argument 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. 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. The device reports online user traffic statistics in accounting packets. The traffic measurement units are configurable, but they must be the same as the traffic measurement units configured on the RADIUS accounting servers. To set the username format and the traffic statistics units for a RADIUS scheme: 2. Enter RADIUS scheme view. 3. Set the format for usernames sent to the RADIUS servers. 4. (Optional.) Set the data flow and packet measurement units for traffic statistics. radius scheme radius-scheme-name user-name-format { keep-original with-domain without-domain } data-flow-format { data { byte giga-byte kilo-byte mega-byte } packet { giga-packet kilo-packet mega-packet one-packet } } * N/A By default, the ISP domain name is included in a username. By default, traffic is counted in bytes and packets. Setting the maximum number of RADIUS request transmission attempts 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 RADIUS timers." 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. To set the maximum number of RADIUS request transmission attempts: 2. Enter RADIUS scheme view. radius scheme radius-scheme-name N/A 31

48 3. Set the maximum number of RADIUS request transmission attempts. retry retries The default setting is 3. Setting the maximum number of real-time accounting attempts If you specify a maximum number of real-time accounting attempts, the device will disconnect users from which no accounting responses are received within the permitted attempts. To set the maximum number of real-time accounting attempts: 2. Enter RADIUS scheme view. 3. Set the maximum number of real-time accounting attempts. radius scheme radius-scheme-name retry realtime-accounting retries N/A The default setting is 5. Configuring RADIUS stop-accounting packet buffering 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. To configure RADIUS stop-accounting packet buffering: 2. Enter RADIUS scheme view. 3. Set the maximum number of real-time accounting attempts. 4. Enable buffering of RADIUS stop-accounting requests to which no responses have been received. 5. (Optional.) Set the maximum number of transmission attempts for individual RADIUS stop-accounting requests. radius scheme radius-scheme-name retry realtime-accounting retries stop-accounting-buffer enable retry stop-accounting retries N/A The default setting is 5. By default, the buffering feature is enabled. The default setting is

49 Setting the maximum number of pending RADIUS requests About the maximum number of pending RADIUS requests This feature controls the rate of RADIUS requests that are sent to the RADIUS server. Use this feature if the RADIUS server has a limited performance and cannot concurrently process too many RADIUS requests. The device has two types of pending packet counters, one for the RADIUS authentication server and the other for the RADIUS accounting server. A pending packet counter is used to record the number of sent RADIUS requests for which no responses are received from the RADIUS server. The maximum value of a pending packet counter is determined by this command. If you set the maximum number of pending authentication or accounting requests, a pending packet counter will be started for each RADIUS authentication or accounting server. 1. The device starts a pending packet counter for a RADIUS authentication or accounting server after sending the first authentication or accounting request to the server. 2. The device keeps sending the corresponding type of requests to the server before the counter reaches the maximum value. The number of requests that can be sent to the server is the difference between the counter value and the maximum number. The counter increases by 1 each time the device sends a corresponding request. The counter decreases by 1 each time the device receives a respond from the server or the respond timeout timer for a request expires. 3. The device buffers the subsequent requests when the counter reaches the maximum value. If the value of the counter falls below the maximum value, the device sends the buffered requests in the sequence the requests are buffered. Procedure To set the maximum number of pending RADIUS requests: 2. Enter RADIUS scheme view. 3. Set the maximum number of pending RADIUS requests. radius scheme radius-scheme-name response-pending-limit { accounting authentication } max-number N/A By default, the number of pending RADIUS requests is not restricted. Setting the status of RADIUS servers About RADIUS server status 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 communicates with the primary server. If the primary server fails, the device performs the following operations: Changes the server status to blocked. Starts a quiet timer for the server. Tries to communicate with a secondary server in active state that has the highest priority. 33

50 Procedure If the secondary 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. 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 or accounting attempt a failure. 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. 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 all servers are in blocked state, the device only tries to communicate with the primary server. 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 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. 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 AAA request. 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. To set the status of RADIUS servers: 2. Enter RADIUS scheme view. radius scheme radius-scheme-name N/A 34

51 3. Set the RADIUS server status. 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 [ { 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 [ { ipv4-address ipv6 ipv6-address } [ port-number vpn-instance vpn-instance-name ] * ] { active block } By default, a RADIUS server is in active state. 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. Enabling the RADIUS server load sharing feature 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 unavailable, 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. To enable the RADIUS server load sharing feature: 2. Enter RADIUS scheme view. 3. Enable the RADIUS server load sharing feature. radius scheme radius-scheme-name server-load-sharing enable N/A By default, this feature is disabled. 35

52 Specifying the source IP address for outgoing RADIUS packets About source IP address for outgoing RADIUS packets 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, a RADIUS server checks whether the source IP address of the packet is the IP address of a managed NAS. 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. 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 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 in which the RADIUS servers are in a VPN or the public network. 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. Specifying a source IP address for all RADIUS schemes 2. Specify a source IP address for outgoing RADIUS packets. radius nas-ip { ipv4-address ipv6 ipv6-address } [ vpn-instance vpn-instance-name ] By default, the primary IP address of the RADIUS packet outbound interface is used as the source IP address. Specifying a source IP address for a RADIUS scheme 2. Enter RADIUS scheme view. 3. Specify a source IP address for outgoing RADIUS packets. radius scheme radius-scheme-name nas-ip { ipv4-address ipv6 ipv6-address } N/A By default, the source IP address specified by using the radius nas-ip command in system view is used. If the source IP address is not specified, the primary IP address of the outbound interface is used. 36

53 Setting RADIUS timers About RADIUS timers 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 Procedure When you set RADIUS timers, follow these 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. 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. To set RADIUS timers: 2. Enter RADIUS scheme view. 3. Set the RADIUS server response timeout timer. 4. Set the quiet timer for the servers. 5. Set the real-time accounting timer. radius scheme radius-scheme-name timer response-timeout seconds timer quiet minutes timer realtime-accounting interval [ second ] N/A The default setting is 3 seconds. The default setting is 5 minutes. The default setting is 12 minutes. 37

54 Configuring the RADIUS accounting-on feature About RADIUS accounting-on Procedure 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. For the extended accounting-on feature to take effect, the RADIUS server must run on IMC and the accounting-on feature must be enabled. The extended accounting-on feature is applicable to IPoE, LAN, and PPP (L2TP LAC-side) users. The user data is saved to the cards through which the users access the device. When the extended accounting-on feature is enabled, the device automatically sends an accounting-on packet to the RADIUS server after a card reboot. The packet contains the card identifier. Upon receiving the accounting-on packet, the RADIUS server logs out all online users that access the device through the card. To configure the accounting-on feature for a RADIUS scheme: 2. Enter RADIUS scheme view. 3. Enable accounting-on. 4. (Optional.) Enable extended accounting-on. radius scheme radius-scheme-name accounting-on enable [ interval interval send send-times ] * accounting-on extended N/A By default, the accounting-on feature is disabled. By default, extended accounting-on is disabled. Interpreting the RADIUS class attribute as CAR parameters 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. To configure the device to interpret the RADIUS class attribute as CAR parameters: 2. Enter RADIUS scheme view. 3. Interpret the RADIUS class attribute as CAR parameters. radius scheme radius-scheme-name attribute 25 car N/A By default, the RADIUS class attribute is not interpreted as CAR parameters. 38

55 Configuring the Login-Service attribute check method for SSH, FTP, and terminal users About Login-Service attribute check methods 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. 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 To configure the Login-Service attribute check method for SSH, FTP, and terminal users: 2. Enter RADIUS scheme view. 3. Configure the Login-Service attribute check method for SSH, FTP, and terminal users. radius scheme radius-scheme-name attribute 15 check-mode { loose strict } N/A The default check method is strict. Configuring the MAC address format for RADIUS attribute 31 RADIUS servers of different types might have different requirements for the MAC address format in RADIUS attribute 31. Configure the MAC address format for RADIUS attribute 31 to meet the requirements of the RADIUS servers. To configure the MAC address format for RADIUS attribute 31: 2. Enter RADIUS scheme view. 3. Configure the MAC address format for RADIUS attribute 31. radius scheme radius-scheme-name attribute 31 mac-format section { six three } separator separator-character { lowercase uppercase } N/A By default, a MAC address 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. 39

56 Configuring the format for RADIUS attribute 87 About the format for RADIUS attribute 87 RADIUS attribute 87 is the NAS-Port-Id attribute. This attribute has the following format types: Vendor-specific format The attribute format is defined by a vendor. Custom format The attribute format is user defined. You can define the fields to be included in the attribute, the sequence of the fields, and the delimiters to separate the fields. RADIUS servers of different types might have different requirements for the format of the NAS-Port-Id attribute. Configure the format for the NAS-Port-Id attribute to meet the requirements of the RADIUS servers. Procedure To configure the format for RADIUS attribute 87: 2. Enter RADIUS scheme view. 3. Configure the format for RADIUS attribute 87. radius scheme radius-scheme-name attribute 87 format { custom { c-vid [ delimiter ] interface-type [ delimiter ] port [ delimiter ] s-vid [ delimiter ] slot [ delimiter ] string string [ delimiter ] subslot [ delimiter ] } * vendor vendor-id } N/A By default, no format is configured for RADIUS attribute 87 and the device uses the attribute format defined by each access module. Setting the data measurement unit for the Remanent_Volume attribute The Remanent_Volume attribute is H3C proprietary. The RADIUS server uses this attribute in authentication or real-time accounting responses to notify the device of the current amount of data available for online users. Perform this task to set the data measurement unit for the Remanent_Volume attribute. Make sure the configured measurement unit is the same as the user data measurement unit on the RADIUS server. To set the data measurement unit for the Remanent_Volume attribute: 2. Enter RADIUS scheme view. 3. Set the data measurement unit for the Remanent_Volume attribute. radius scheme radius-scheme-name attribute remanent-volume unit { byte giga-byte kilo-byte mega-byte } N/A By default, the data measurement unit is kilobyte. 40

57 Specifying a server version for interoperating with servers with a vendor ID of 2011 For the device to correctly interpret RADIUS attributes from the servers with a vendor ID of 2011, specify a server version that is the same as the version of the RADIUS servers. To specify a server version for interoperating with servers with a vendor ID of 2011: Step Commands Remarks 2. Enter RADIUS scheme view. 3. Specify a server version for interoperating with servers with a vendor ID of radius scheme radius-scheme-name attribute vendor-id 2011 version { } N/A By default, version 1.0 is used. Configuring the RADIUS attribute translation feature About RADIUS attribute translation 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). 41

58 Configuring the RADIUS attribute translation feature for a RADIUS scheme 2. (Optional.) Define an extended RADIUS attribute. 3. Enter RADIUS scheme view. 4. Enable the RADIUS attribute translation feature. 5. Configure a RADIUS attribute conversion rule. 6. Configure a RADIUS attribute rejection rule. radius attribute extended attribute-name [ vendor vendor-id ] code attribute-code type { binary date integer interface-id ip ipv6 ipv6-prefix octets string } radius scheme radius-scheme-name attribute translate attribute convert src-attr-name to dest-attr-name { { access-accept access-request accounting } * { received sent } * } attribute reject attr-name { { access-accept access-request accounting } * { received sent } * } By default, no user-defined extended RADIUS attributes exist. Repeat this command to define multiple extended RADIUS attributes. N/A By default, this feature is disabled. By default, no RADIUS attribute conversion rules exist. Repeat this command to add multiple RADIUS attribute conversion rules. By default, no RADIUS attribute rejection rules exist. Repeat this command to add multiple RADIUS attribute rejection rules. Configuring the RADIUS attribute translation feature for a RADIUS DAS 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 } By default, no user-defined extended RADIUS attributes exist. Repeat this command to define multiple extended RADIUS attributes. 3. Enter RADIUS DAS view. radius dynamic-author server N/A 4. Enable the RADIUS attribute translation feature. 5. Configure a RADIUS attribute conversion rule. 6. Configure a RADIUS attribute rejection rule. attribute translate attribute convert src-attr-name to dest-attr-name { { coa-ack coa-request } * { received sent } * } attribute reject attr-name { { coa-ack coa-request } * { received sent } * } By default, this feature is disabled. By default, no RADIUS attribute conversion rules exist. Repeat this command to add multiple RADIUS attribute conversion rules. By default, no RADIUS attribute rejection rules exist. Repeat this command to add multiple RADIUS attribute rejection rules. 42

59 Configuring the RADIUS session-control feature About RADIUS session-control Enable this feature for the RADIUS server to dynamically change the user authorization information or forcibly disconnect users by using session-control packets. This task enables the device to receive RADIUS session-control packets on UDP port 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 When you configure the RADIUS session-control feature, follow these 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. The IP, VPN instance, and shared key settings of a session-control client must be the same as the corresponding settings of the RADIUS server. Procedure To configure the RADIUS session-control feature: 2. Enable the session-control feature. 3. Specify a session-control client. radius session-control enable radius session-control client { ip ipv4-address ipv6 ipv6-address } [ key { cipher simple } string vpn-instance vpn-instance-name ] * By default, the session-control feature is disabled. By default, no session-control clients are specified. Configuring the RADIUS DAS feature About RADIUS DAE server Dynamic Authorization Extensions (DAE) to RADIUS, defined in RFC 5176, can log off online users, change their authorization information, or shut down and then bring up their access interfaces. DAE uses the client/server model. 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, or shuts down and then brings up their access interfaces. 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 for the following purposes: 43

60 Procedure Change the authorization information of specific online users. Shut down and then bring up the access interfaces of users. To configure the RADIUS DAS feature: 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. 4. Specify the RADIUS DAS port. client { ip ipv4-address ipv6 ipv6-address } [ key { cipher simple } string vpn-instance vpn-instance-name ] * port port-number By default, no RADIUS DACs are specified. By default, the RADIUS DAS port is Changing the DSCP priority for RADIUS packets The DSCP priority in the ToS field determines the transmission priority of RADIUS packets. A larger value represents a higher priority. To change the DSCP priority for RADIUS packets: 2. Change the DSCP priority for RADIUS packets. radius [ ipv6 ] dscp dscp-value By default, the DSCP priority is 0 for RADIUS packets. Configuring the device to preferentially process RADIUS authentication requests About configuring the device to preferentially process RADIUS authentication requests RADIUS requests include RADIUS authentication requests, RADIUS accounting-start requests, RADIUS accounting-update requests, and RADIUS accounting-stop requests. By default, the device processes the RADIUS requests in the sequence that the requests are initiated. When a large number of users go offline and then try to come online immediately, authentication might fail for these users because of authentication request timeout. To resolve this issue, configure the device to preferentially process authentication requests. Restrictions and guidelines Do not perform this task if the RADIUS server identifies users by the username and does not allow repeated authentication for the same username. A violation might cause authentication failure for users that try to come online immediately after going offline. As a best practice, do not perform this task when the device has online users. Procedure To configure the device to preferentially process RADIUS authentication requests: 44

61 2. Configure the device to preferentially process RADIUS authentication requests. radius authentication-request first By default, the device processes RADIUS requests in the sequence that the requests are initiated. Enabling SNMP notifications for RADIUS 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. To enable SNMP notifications for RADIUS: 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. Display and maintenance commands for RADIUS Execute display commands in any view and reset commands in user view. Task Display the RADIUS scheme configuration. Display RADIUS packet statistics. Display information about buffered RADIUS stop-accounting requests to which no responses have been received. Clear RADIUS statistics. Clear the buffered RADIUS stop-accounting requests to which no responses have been received. Command display radius scheme [ radius-scheme-name ] display radius statistics display stop-accounting-buffer { radius-scheme radius-scheme-name session-id session-id time-range start-time end-time user-name user-name } reset radius statistics reset stop-accounting-buffer { radius-scheme radius-scheme-name session-id session-id time-range start-time end-time user-name user-name } 45

62 Configuring HWTACACS HWTACACS tasks at a glance Tasks at a glance (Required.) Creating an HWTACACS scheme (Required.) Specifying the HWTACACS authentication servers (Optional.) Specifying the HWTACACS authorization servers (Optional.) Specifying the HWTACACS accounting servers (Required.) Specifying the shared keys for secure HWTACACS communication (Optional.) Specifying an MPLS L3VPN instance for the scheme (Optional.) Setting the username format and traffic statistics units (Optional.) Configuring HWTACACS stop-accounting packet buffering (Optional.) Specifying the source IP address for outgoing HWTACACS packets (Optional.) Setting HWTACACS timers Creating an HWTACACS scheme Create an HWTACACS scheme before performing any other HWTACACS configurations. You can configure a maximum of 16 HWTACACS schemes. An HWTACACS scheme can be used by multiple ISP domains. To create an HWTACACS scheme: 2. Create an HWTACACS scheme and enter HWTACACS scheme view. hwtacacs scheme hwtacacs-scheme-name By default, no HWTACACS schemes exist. Specifying the HWTACACS authentication servers You can specify one primary authentication server and a maximum of 16 secondary authentication 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. 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. To specify HWTACACS authentication servers for an HWTACACS scheme: 46

63 2. Enter HWTACACS scheme view. 3. Specify HWTACACS authentication servers. hwtacacs scheme hwtacacs-scheme-name Specify the primary HWTACACS authentication server: primary authentication { ipv4-address ipv6 ipv6-address } [ port-number key { cipher simple } string single-connection vpn-instance vpn-instance-name ] * Specify a secondary HWTACACS authentication server: secondary authentication { ipv4-address ipv6 ipv6-address } [ port-number key { cipher simple } string single-connection vpn-instance vpn-instance-name ] * N/A By default, no authentication servers are specified. Two HWTACACS authentication servers in a scheme, primary or secondary, cannot have the same combination of IP address, port number, and VPN instance. Specifying the HWTACACS authorization servers 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. 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. To specify HWTACACS authorization servers for an HWTACACS scheme: 2. Enter HWTACACS scheme view. 3. Specify HWTACACS authorization servers. hwtacacs scheme hwtacacs-scheme-name Specify the primary HWTACACS authorization server: primary authorization { ipv4-address ipv6 ipv6-address } [ port-number key { cipher simple } string single-connection vpn-instance vpn-instance-name ] * Specify a secondary HWTACACS authorization server: secondary authorization { ipv4-address ipv6 ipv6-address } [ port-number key { cipher simple } string single-connection vpn-instance vpn-instance-name ] * N/A By default, no authorization servers are specified. Two HWTACACS authorization servers in a scheme, primary or secondary, cannot have the same combination of IP address, port number, and VPN instance. 47

64 Specifying the HWTACACS accounting servers 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. If redundancy is not required, specify only the primary server. 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. HWTACACS does not support accounting for FTP, SFTP, and SCP users. To specify HWTACACS accounting servers for an HWTACACS scheme: 2. Enter HWTACACS scheme view. 3. Specify HWTACACS accounting servers. hwtacacs scheme hwtacacs-scheme-name Specify the primary HWTACACS accounting server: primary accounting { ipv4-address ipv6 ipv6-address } [ port-number key { cipher simple } string single-connection vpn-instance vpn-instance-name ] * Specify a secondary HWTACACS accounting server: secondary accounting { ipv4-address ipv6 ipv6-address } [ port-number key { cipher simple } string single-connection vpn-instance vpn-instance-name ] * N/A By default, no accounting servers are specified. Two HWTACACS accounting servers in a scheme, primary or secondary, cannot have the same combination of IP address, port number, and VPN instance. Specifying the shared keys for secure HWTACACS communication 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. To specify a shared key for secure HWTACACS communication: 2. Enter HWTACACS scheme view. hwtacacs scheme hwtacacs-scheme-name N/A 48

65 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. The shared key configured on the device must be the same as the shared key configured on the HWTACACS server. Specifying an MPLS L3VPN instance for the scheme 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. To specify a VPN instance for an HWTACACS scheme: 2. Enter HWTACACS scheme view. 3. Specify a VPN instance for the HWTACACS scheme. hwtacacs scheme hwtacacs-scheme-name vpn-instance vpn-instance-name N/A By default, an HWTACACS scheme belongs to the public network. Setting the username format and traffic statistics units A username is typically in the userid@isp-name format, where the isp-name argument 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. 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. The device reports online user traffic statistics in accounting packets. The traffic measurement units are configurable, but they must be the same as the traffic measurement units configured on the HWTACACS accounting servers. To set the username format and traffic statistics units for an HWTACACS scheme: 2. Enter HWTACACS scheme view. 3. Set the format of usernames sent to the HWTACACS servers. 4. (Optional.) Set the data flow and packet measurement units for traffic statistics. hwtacacs scheme hwtacacs-scheme-name user-name-format { keep-original with-domain without-domain } data-flow-format { data { byte giga-byte kilo-byte mega-byte } packet { giga-packet kilo-packet mega-packet one-packet } } * N/A By default, the ISP domain name is included in a username. By default, traffic is counted in bytes and packets. 49

66 Configuring HWTACACS stop-accounting packet buffering 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. To configure HWTACACS stop-accounting packet buffering: 2. Enter HWTACACS scheme view. 3. Enable buffering of HWTACACS stop-accounting requests to which no responses have been received. 4. (Optional.) Set the maximum number of transmission attempts for individual HWTACACS stop-accounting requests. hwtacacs scheme hwtacacs-scheme-name stop-accounting-buffer enable N/A By default, the buffering feature is enabled. retry stop-accounting retries The default setting is 100. Specifying the source IP address for outgoing HWTACACS packets About source IP address for outgoing HWTACACS packets 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 whether the source IP address of the packet is the IP address of a managed NAS. 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. 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. Restrictions and guidelines for specifying the source IP address for outgoing HWTACACS packets 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. 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 in which the HWTACACS servers are in a VPN or the public network. 50

67 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. Specifying a source IP address for all HWTACACS schemes 2. Specify a source IP address for outgoing HWTACACS packets. hwtacacs nas-ip { ipv4-address ipv6 ipv6-address } [ vpn-instance vpn-instance-name ] By default, the primary IP address of the HWTACACS packet outbound interface is used as the source IP address. Specifying a source IP address for an HWTACACS scheme 2. Enter HWTACACS scheme view. 3. Specify the source IP address of outgoing HWTACACS packets. hwtacacs scheme hwtacacs-scheme-name nas-ip { ipv4-address ipv6 ipv6-address } N/A By default, the source IP address specified by using the hwtacacs nas-ip command in system view is used. If the source IP address is not specified, the primary IP address of the outbound interface is used. Setting HWTACACS timers About HWTACACS timers and server status 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. If the primary server fails, the device performs the following operations: Changes the server status to blocked. Starts a quiet timer for the server. 51

68 Tries to communicate with a secondary server in active state that has the highest priority. If the secondary 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. 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. When the quiet timer of a 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. 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 all servers are in blocked state, the device only tries to communicate with the primary server. When one or more servers are in active state, the device tries to communicate with these servers only, even if they are unavailable. 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 Procedure 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. To set HWTACACS timers: 2. Enter HWTACACS scheme view. 3. Set the HWTACACS server response timeout timer. 4. Set the real-time accounting interval. hwtacacs scheme hwtacacs-scheme-name timer response-timeout seconds timer realtime-accounting minutes N/A By default, the HWTACACS server response timeout timer is 5 seconds. By default, the real-time accounting interval is 12 minutes. A short interval helps improve accounting precision but requires many system resources. When there are 1000 or more users, set a longer interval. 5. Set the server quiet timer. timer quiet minutes By default, the server quiet timer is 5 minutes. Display and maintenance commands for HWTACACS Execute display commands in any view and reset commands in user view. 52

69 Task Display the configuration or server statistics of HWTACACS schemes. Display information about buffered HWTACACS stop-accounting requests to which no responses have been received. Clear HWTACACS statistics. Clear the buffered HWTACACS stop-accounting requests to which no responses have been received. Command display hwtacacs scheme [ hwtacacs-scheme-name [ statistics ] ] display stop-accounting-buffer hwtacacs-scheme hwtacacs-scheme-name reset hwtacacs statistics { accounting all authentication authorization } reset stop-accounting-buffer hwtacacs-scheme hwtacacs-scheme-name Configuring LDAP LDAP tasks at a glance Tasks at a glance Configuring an LDAP server: (Required.) Creating an LDAP server (Required.) Configuring the IP address of the LDAP server (Optional.) Specifying the LDAP version (Optional.) Setting the LDAP server timeout period (Required.) Configuring administrator attributes (Required.) Configuring LDAP user attributes (Optional.) Configuring an LDAP attribute map (Required.) Creating an LDAP scheme (Required.) Specifying the LDAP authentication server (Optional.) Specifying the LDAP authorization server (Optional.) Specifying an LDAP attribute map for LDAP authorization Creating an LDAP server 2. Create an LDAP server and enter LDAP server view. ldap server server-name By default, no LDAP servers exist. Configuring the IP address of the LDAP server 53

70 2. Enter LDAP server view. ldap server server-name N/A 3. Configure the IP address of the LDAP server. { ip ip-address ipv6 ipv6-address } [ port port-number ] [ vpn-instance vpn-instance-name ] By default, an LDAP server does not have an IP address. You can configure either an IPv4 address or an IPv6 address for an LDAP server. The most recent configuration takes effect. Specifying the LDAP version Specify the LDAP version on the NAS. The device supports LDAPv2 and LDAPv3. The LDAP version specified on the device must be consistent with the version specified on the LDAP server. To specify the LDAP version: 2. Enter LDAP server view. ldap server server-name N/A 3. Specify the LDAP version. protocol-version { v2 v3 } By default, LDAPv3 is used. A Microsoft LDAP server supports only LDAPv3. Setting the LDAP server timeout period 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. To set the LDAP server timeout period: 2. Enter LDAP server view. ldap server server-name N/A 3. Set the LDAP server timeout period. server-timeout time-interval By default, the LDAP server timeout period is 10 seconds. Configuring administrator attributes To configure the administrator DN and password for binding with the LDAP server during LDAP authentication: 2. Enter LDAP server view. ldap server server-name N/A 54

71 3. Specify the administrator DN. 4. Configure the administrator password. login-dn dn-string login-password { cipher simple } 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. By default, no administrator password is specified. Configuring LDAP user attributes 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. 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. To configure LDAP user attributes: 2. Enter LDAP server view. ldap server server-name N/A 3. Specify the user search base DN. 4. (Optional.) Specify the user search scope. 5. (Optional.) Specify the username attribute. 6. (Optional.) Specify the username format. search-base-dn base-dn search-scope { all-level single-level } user-parameters user-name-attribute { name-attribute cn uid } user-parameters user-name-format { with-domain without-domain } By default, no user search base DN is specified. By default, the user search scope is all-level. By default, the username attribute is cn. By default, the username format is without-domain. 55

72 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 LDAP server model. Configuring an LDAP attribute map 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. To configure an LDAP attribute map: 2. Create an LDAP attribute map and enter LDAP attribute map view. ldap attribute-map map-name By default, no LDAP attribute maps exist. 3. Configure a mapping entry. map ldap-attribute ldap-attribute-name [ prefix prefix-value delimiter delimiter-value ] aaa-attribute { user-group user-profile } By default, an LDAP attribute map does not have any mapping entries. Repeat this command to configure multiple mapping entries. Creating an LDAP scheme You can configure a maximum of 16 LDAP schemes. An LDAP scheme can be used by multiple ISP domains. To create an LDAP scheme: 2. Create an LDAP scheme and enter LDAP scheme view. ldap scheme ldap-scheme-name By default, no LDAP schemes exist. 56

73 Specifying the LDAP authentication server 2. Enter LDAP scheme view. ldap scheme ldap-scheme-name N/A 3. Specify the LDAP authentication server. authentication-server server-name By default, no LDAP authentication server is specified. Specifying the LDAP authorization server 2. Enter LDAP scheme view. ldap scheme ldap-scheme-name N/A 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 Specify an LDAP attribute map for LDAP authorization to convert LDAP attributes obtained from the LDAP authorization server to device-recognizable AAA attributes. You can specify only one LDAP attribute map in an LDAP scheme. To specify an LDAP attribute map for LDAP authorization: 2. Enter LDAP scheme view. ldap scheme ldap-scheme-name N/A 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 the configuration of LDAP schemes. display ldap scheme [ ldap-scheme-name ] 57

74 Configuring AAA methods for ISP domains 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. (Support for the authentication domain configuration depends on 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. If no such ISP domain is configured, user authentication fails. Restrictions and guidelines When you configure an ISP domain, follow these restrictions and guidelines: 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. Procedure To create an ISP domain: 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. 3. Return to system view. quit N/A 4. (Optional.) Specify the default ISP domain. 5. (Optional.) Specify the ISP domain to accommodate users that are assigned to nonexistent domains. domain default enable isp-name domain if-unknown isp-domain-name By default, the default ISP domain is the system-defined ISP domain system. By default, no ISP domain is specified to accommodate users that are assigned to nonexistent domains. 58

75 Configuring ISP domain attributes Setting ISP domain status By placing the ISP domain in active or blocked state, you allow or deny network service requests from users in the domain. To set ISP domain status: 2. Enter ISP domain view. domain isp-name N/A 3. Place the ISP domain in active or blocked state. 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 The device assigns the authorization attributes in the ISP domain to the authenticated users that do not receive these attributes from the server. However, if the idle cut attribute is configured in the ISP domain, the device assigns the attribute to the authenticated users. If no idle cut attribute is configured in the ISP domain, the device uses the idle cut attribute assigned by the server. The device supports the following authorization attributes: Authorization ACL The device restricts authenticated users to access only the network resources permitted by the ACL. Authorization CAR action The attribute controls the traffic flow of authenticated users. Idle cut It enables the device to check the traffic of each online user at the specified direction in the domain at the idle timeout interval. The device logs out an online user if the user's total traffic in the idle timeout period at the specified direction is less than the specified minimum traffic. IPv4 address pool The device assigns IPv4 addresses from the pool to authenticated users in the domain. Default authorization user profile When a user passes authentication, it typically obtains an authorization user profile from the local or remote server. If the user does not obtain any user profile, the device authorizes the default user profile of the ISP domain to the user. The device will restrict the user's behavior based on the profile. Authorization session group profile The device restricts authenticated users' behaviors based on the settings in the authorization session group profile. Authorization session timeout timer The device logs out a user when the session timeout timer for the user expires. Authorization IPv6 address prefix The device authorizes the IPv6 address prefix to authenticated users in the domain. IPv6 address pool The device assigns IPv6 addresses from the pool to authenticated users in the domain. DNS server address The attribute specifies the DNS server that offers DNS services to the authenticated users in the domain. Redirect URL The device redirects PPP users in the domain to the URL after they pass authentication. Authorization user group Authenticated users in the domain obtain all attributes of the user group. 59

76 Authorization VPN instance The device allows authenticated PPP and IPoE users in the domain to access network resources in the authorization VPN. Maximum number of multicast groups The attribute restricts the maximum number of multicast groups that an authenticated IPoE, portal, or PPP user can join concurrently. User priority The device uses the user priority to perform QoS priority mapping on user packets, and then assigns the user packets to a queue based on the target priority. Packets in a high-priority queue are preferentially scheduled when congestion occurs. When you configure authorization attributes for an ISP domain, follow these restrictions and guidelines: The lowest committed information rate you can set is 8 kbps. Do not configure an authorization VPN instance in the ISP domain if IPoE, portal, and PPPoE users in the domain access the network through the SPC, CSPC, and CMPE-1104 cards. A violation will prevent the device from performing accounting on ITA service traffic for the users. Portal users might have both the preauthentication IP address pool and the authorization IP address pool. The two DHCP address pools must both have the export-route keyword specified or not specified in the gateway-list or network command. For more information about DHCP address pools, see "Configuring DHCP." You can use the dhcp server apply ip-pool or portal [ ipv6 ] pre-auth ip-pool command to specify a DHCP address pool as the preauthentication IP address pool for portal users on an interface. For more information about the dhcp server apply ip-pool, portal [ ipv6 ] pre-auth ip-pool, gateway-list, and network commands, see BRAS Services Command Reference. The user group to be configured as an authorization user group must already exist. To avoid mistakenly logging out online users, do not delete the authorization user group if the user group has online users. For IPoE users that perform Web authentication, authorization attributes can be configured in a preauthentication domain to restrict user behaviors before the users pass authentication. To configure authorization attributes for an ISP domain: 2. Enter ISP domain view. domain isp-name N/A 60

77 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 ] idle-cut minutes [ flow ] [ traffic { both inbound outbound } ] igmp max-access-number max-access-number ip-pool pool-name ipv6-pool ipv6-pool-name ipv6-prefix ipv6-prefix prefix-length mld max-access-number max-access-number { primary-dns secondary-dns } { ip ipv4-address ipv6 ipv6-address } session-group-profile session-group-profile-name session-timeout timeout url url-string user-group user-group-name user-priority { inbound outbound } priority user-profile profile-name vpn-instance vpn-instance-name } The default settings are as follows: The idle cut feature is disabled. 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. The user-priority attribute takes effect only on SPEX cards (excluding the CSPEX-1204 card). For IPoE, portal, and PPP users that access the network through Layer 3 aggregate interfaces or Layer 3 aggregate subinterfaces, you can apply the authorization user priority only to upstream packets of users. The user-profile attribute takes effect only on CSPEX cards. The session-group-profile attribute does not take effect. Including the idle timeout period in the user online duration to be sent to the server 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. The online duration that is generated on the server is longer than the actual online duration of the user. Typically, the idle timeout period is authorized by the authorization server after users pass authentication. For portal users, the idle timeout period set for the online portal user detection feature takes priority over the server-assigned idle timeout period. For more information about online detection for portal users, see "Configuring portal authentication." To include the idle timeout period in the user online duration to be sent to the server: 2. Enter ISP domain view. domain isp-name N/A 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 By default, the user online duration sent to the server excludes the idle timeout period. Specifying the user address type in an ISP domain 2. Enter ISP domain view. domain isp-name N/A 61

78 3. Specify the user address type in the ISP domain. user-address-type { ds-lite ipv6 nat64 private-ds private-ipv4 public-ds public-ipv4 } Specifying the service type for users in an ISP domain 2. Enter ISP domain view. domain isp-name N/A By default, no user address type is specified. 3. Specify the service type for users in the ISP domain. service-type { hsi stb voip } By default, the service type is hsi. Applying an ITA policy to users in an ISP domain IMPORTANT: This feature takes effect only on CSPEX cards. The attribute allows the device to perform accounting at different charge rates for user data based on destination addresses. The ITA policy assigned from an AAA server takes precedence over the ITA policy in an ISP domain. To apply an ITA policy to users in an ISP domain: 2. Enter ISP domain view. domain isp-name N/A 3. Apply an ITA policy to users in the ISP domain. ita-policy policy-name By default, no ITA policy is applied. Configuring authentication methods for an ISP domain Restrictions and guidelines When configuring authentication methods, follow these 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 the 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. When the primary authentication method is local, the following rules apply to the authentication of a user: The device uses the backup authentication methods in sequence only if local authentication is invalid for one of the following reasons: An exception occurs in the AAA process. The user disconnects from the device. 62

79 Prerequisites Procedure The user account is not configured on the device or the user is not allowed to use the access service. The device does not turn to the backup authentication methods if local authentication is invalid because of any other reason. Authentication fails for the user. 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. To configure authentication methods for an ISP domain: 2. Enter ISP domain view. domain isp-name N/A 3. Specify default authentication methods for all types of users. 4. Specify authentication methods for IPoE users. 5. Specify authentication methods for LAN users. 6. Specify authentication methods for login users. authentication default { hwtacacs-scheme hwtacacs-scheme-name [ radius-scheme radius-scheme-name ] [ local ] [ none ] ldap-scheme ldap-scheme-name [ local ] [ none ] local [ radius-scheme radius-scheme-name hwtacacs-scheme hwtacacs-scheme-name ] * [ none ] local [ ldap-scheme ldap-scheme-name ] [ none ] none radius-scheme radius-scheme-name [ hwtacacs-scheme hwtacacs-scheme-name ] [ local ] [ none ] } authentication ipoe { local [ radius-scheme radius-scheme-name ] [ none ] none radius-scheme radius-scheme-name [ local ] [ none ] } authentication lan-access { ldap-scheme ldap-scheme-name [ local ] [ none ] local [ ldap-scheme ldap-scheme-name radius-scheme radius-scheme-name ] [ none ] none radius-scheme radius-scheme-name [ local ] [ none ] } authentication login { hwtacacs-scheme hwtacacs-scheme-name [ radius-scheme radius-scheme-name ] [ local ] [ none ] ldap-scheme ldap-scheme-name [ local ] [ none ] local [ radius-scheme radius-scheme-name hwtacacs-scheme hwtacacs-scheme-name ] * [ none ] local [ ldap-scheme ldap-scheme-name ] [ none ] none radius-scheme radius-scheme-name [ hwtacacs-scheme hwtacacs-scheme-name ] [ local ] [ none ] } By default, the default authentication method is local. By default, the default authentication method is used for IPoE users. This command takes effect only on CSPEX cards. By default, the default authentication method is used for LAN users. By default, the default authentication method is used for login users. 63

80 7. Specify authentication methods for portal users. authentication portal { ldap-scheme ldap-scheme-name [ local ] [ none ] local [ ldap-scheme ldap-scheme-name radius-scheme radius-scheme-name ] [ none ] none radius-scheme radius-scheme-name [ local ] [ none ] } By default, the default authentication method is used for portal users. This command takes effect only on CSPEX cards. 8. Specify authentication methods for PPP users. 9. Specify authentication methods for obtaining a temporary user role. authentication ppp { hwtacacs-scheme hwtacacs-scheme-name [ radius-scheme radius-scheme-name ] [ local ] [ none ] local [ radius-scheme radius-scheme-name hwtacacs-scheme hwtacacs-scheme-name ] * [ none ] none radius-scheme radius-scheme-name [ hwtacacs-scheme hwtacacs-scheme-name ] [ local ] [ none ] } authentication super { hwtacacs-scheme hwtacacs-scheme-name radius-scheme radius-scheme-name } * By default, the default authentication method is used for PPP users. By default, the default authentication method is used for obtaining a temporary user role. Configuring authorization methods for an ISP domain Restrictions and guidelines When configuring authorization methods, follow these guidelines: The device supports HWTACACS authorization but not LDAP authorization. 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. When the primary authorization method is local, the following rules apply to the authorization of a user: The device uses the backup authorization methods in sequence only if local authorization is invalid for one of the following reasons: An exception occurs in the AAA process. The user disconnects from the device. The user account is not configured on the device or the user is not allowed to use the access service. The device does not turn to the backup authorization methods if local authorization is invalid because of any other reason. Authorization fails for the user. 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 To configure authorization methods for an ISP domain: 64

81 2. Enter ISP domain view. domain isp-name N/A 3. Specify default authorization methods for all types of users. 4. Specify command authorization methods. 5. Specify authorization methods for IPoE users. 6. Specify authorization methods for LAN users. 7. Specify authorization methods for login users. 8. Specify authorization methods for portal users. authorization default { hwtacacs-scheme hwtacacs-scheme-name [ radius-scheme radius-scheme-name ] [ local ] [ none ] local [ radius-scheme radius-scheme-name hwtacacs-scheme hwtacacs-scheme-name ] * [ none ] none radius-scheme radius-scheme-name [ hwtacacs-scheme hwtacacs-scheme-name ] [ local ] [ none ] } authorization command { hwtacacs-scheme hwtacacs-scheme-name [ local ] [ none ] local [ none ] none } authorization ipoe { local [ radius-scheme radius-scheme-name ] [ none ] none radius-scheme radius-scheme-name [ local ] [ none ] } authorization lan-access { local [ radius-scheme radius-scheme-name ] [ none ] none radius-scheme radius-scheme-name [ local ] [ none ] } authorization login { hwtacacs-scheme hwtacacs-scheme-name [ radius-scheme radius-scheme-name ] [ local ] [ none ] local [ radius-scheme radius-scheme-name hwtacacs-scheme hwtacacs-scheme-name ] * [ none ] none radius-scheme radius-scheme-name [ hwtacacs-scheme hwtacacs-scheme-name ] [ local ] [ none ] } authorization portal { local [ radius-scheme radius-scheme-name ] [ none ] none radius-scheme radius-scheme-name [ local ] [ none ] } By default, the authorization method is local. By default, the default authorization method is used for command authorization. By default, the default authorization method is used for IPoE users. This command takes effect only on CSPEX cards. By default, the default authorization method is used for LAN users. By default, the default authorization method is used for login users. By default, the default authorization method is used for portal users. This command takes effect only on CSPEX cards. 65

82 9. Specify authorization methods for PPP users. authorization ppp { hwtacacs-scheme hwtacacs-scheme-name [ radius-scheme radius-scheme-name ] [ local ] [ none ] local [ radius-scheme radius-scheme-name hwtacacs-scheme hwtacacs-scheme-name ] * [ none ] none radius-scheme radius-scheme-name [ hwtacacs-scheme hwtacacs-scheme-name ] [ local ] [ none ] } By default, the default authorization method is used for PPP users. Configuring accounting methods for an ISP domain Restrictions and guidelines Prerequisites Procedure When configuring accounting methods, follow these 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. When the primary accounting method is local, the following rules apply to the accounting of a user: The device uses the backup accounting methods in sequence only if local accounting is invalid for one of the following reasons: An exception occurs in the AAA process. The user disconnects from the device. The user account is not configured on the device or the user is not allowed to use the access service. The device does not turn to the backup accounting methods if local accounting is invalid because of any other reason. Accounting fails for the user. 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. To configure accounting methods for an ISP domain: 2. Enter ISP domain view. domain isp-name N/A 66

83 3. Specify default accounting methods for all types of users. accounting default { hwtacacs-scheme hwtacacs-scheme-name [ radius-scheme radius-scheme-name ] [ local ] [ none ] local [ radius-scheme radius-scheme-name hwtacacs-scheme hwtacacs-scheme-name ] * [ none ] none radius-scheme radius-scheme-name [ hwtacacs-scheme hwtacacs-scheme-name ] [ local ] [ none ] } By default, the accounting method is local. 4. Specify the command accounting method. 5. Specify accounting methods for IPoE users. 6. Specify accounting methods for LAN users. 7. Specify accounting methods for login users. 8. Specify accounting methods for portal users. accounting command hwtacacs-scheme hwtacacs-scheme-name accounting ipoe { broadcast radius-scheme radius-scheme-name1 radius-scheme radius-scheme-name2 [ local ] [ none ] local [ radius-scheme radius-scheme-name ] [ none ] none radius-scheme radius-scheme-name [ local ] [ none ] } accounting lan-access { broadcast radius-scheme radius-scheme-name1 radius-scheme radius-scheme-name2 [ local ] [ none ] local [ radius-scheme radius-scheme-name ] [ none ] none radius-scheme radius-scheme-name [ local ] [ none ] } accounting login { hwtacacs-scheme hwtacacs-scheme-name [ radius-scheme radius-scheme-name ] [ local ] [ none ] local [ radius-scheme radius-scheme-name hwtacacs-scheme hwtacacs-scheme-name ] * [ none ] none radius-scheme radius-scheme-name [ hwtacacs-scheme hwtacacs-scheme-name ] [ local ] [ none ] } accounting portal { broadcast radius-scheme radius-scheme-name1 radius-scheme radius-scheme-name2 [ local ] [ none ] local [ radius-scheme radius-scheme-name ] [ none ] none radius-scheme radius-scheme-name [ local ] [ none ] } By default, the default accounting method is used for command accounting. By default, the default accounting method is used for IPoE users. This command takes effect only on CSPEX cards. By default, the default accounting method is used for LAN users. By default, the default accounting method is used for login users. By default, the default accounting method is used for portal users. This command takes effect only on CSPEX cards. 67

84 9. Specify accounting methods for PPP users. accounting ppp { broadcast radius-scheme radius-scheme-name1 radius-scheme radius-scheme-name2 [ hwtacacs-scheme hwtacacs-scheme-name ] [ local ] [ none ] hwtacacs-scheme hwtacacs-scheme-name [ radius-scheme radius-scheme-name ] [ local ] [ none ] local [ radius-scheme radius-scheme-name hwtacacs-scheme hwtacacs-scheme-name ] * [ none ] none radius-scheme radius-scheme-name [ hwtacacs-scheme hwtacacs-scheme-name ] [ local ] [ none ] } By default, the default accounting method is used for PPP users. 10. Configure access control for users that encounter accounting-start failures. 11. Configure access control for users that have failed all their accounting-update attempts. 12. Configure access control for users that have used up their data quotas. 13. Specify the accounting method for dual-stack users. accounting start-fail { offline online } accounting update-fail { [ max-times max-times ] offline online } accounting quota-out { offline online } accounting dual-stack { merge separate } By default, the device allows users that encounter accounting-start failures to stay online. This command takes effect only on CSPEX cards. By default, the device allows users that have failed all their accounting-update attempts to stay online. This command takes effect only on CSPEX cards. By default, the device logs off users that have used up their data quotas. This command takes effect only on CSPEX cards. By default, the merge method is used. Display and maintenance commands for ISP domains Execute display commands in any view. Task Display configuration information about an ISP domain or all ISP domains. (In standalone mode.) Display history peak statistics of users. (In IRF mode.) Display history peak statistics of users. Command display domain [ isp-name ] display max-user history [ slot slot-number ] display max-user history [ chassis chassis-number slot slot-number ] 68

85 Setting the maximum number of concurrent login users 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. To set the maximum number of concurrent login users: 2. Set the maximum number of concurrent login users. aaa session-limit { ftp ssh telnet } max-sessions By default, the maximum number of concurrent login users is 32 for each user type. Configuring the local bill cache feature About local bill cache The local bill cache stores accounting bills locally for users that encounter accounting-stop failures (for example, failures caused by unreachable servers). The accounting bills include the following information: Start and stop timestamps for accounting sessions. User access information. Accounting traffic statistics. Local accounting bills can be exported to a storage directory by using FTP or TFTP. When an accounting server becomes available, it can download the accounting bills from the directory. The following mechanisms are available for exporting accounting bills: Automatic mechanism The system automatically exports the accounting bills at regular intervals or when the number of bills reaches a system-defined threshold. The local bill cache is cleared each time the system finishes an automatic bill export process. Manual mechanism The system exports the accounting bills when the local-bill export command is used. If the clear-cache keyword is specified, the system clears the local bill cache. Automatic bill export supports SNMP notification. When an automatic bill export fails, the system sends notification messages to the information center. The local bill cache feature is applicable to LAN, portal, PPP, and IPoE users. Procedure To configure the local bill cache feature: 2. Enable the local bill cache feature. local-bill enable By default, this feature is disabled. 69

86 3. Specify the destination URL for exporting accounting bills. 4. Set an interval at which accounting bills are exported automatically. 5. (Optional.) Enable SNMP notification for automatic bill export. 6. Export the accounting bills manually to the specified URL. local-bill export-url url local-bill export-interval interval snmp-agent trap enable local-bill local-bill export [ url ] [ clear-cache ] By default, no URL is specified. By default, the interval is 1440 minutes. By default, SNMP notification is enabled for automatic bill export. N/A Display and maintenance commands for local bill cache Execute display commands in any view. Task Display detailed information about a series of consecutive accounting bills. Display usage statistics of the local bill cache. Command display local-bill verbose start-number count count display local-bill cache-usage Configuring a NAS-ID About NAS-IDs 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. You can configure a NAS-ID in NAS-ID profile view, in interface view, or in ISP domain view. The device selects the NAS-ID for the NAS-Identifier attribute in the following order: 1. NAS-ID bound with VLANs in a NAS-ID profile. 2. NAS-ID on an interface. 3. NAS-ID in an ISP domain. If no NAS-ID is selected, the device uses the device name (set by using the sysname command) as the NAS-ID. Configuring a NAS-ID profile 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. You can apply a NAS-ID profile to portal-enabled interfaces. For more information, see "Configuring portal authentication." A NAS-ID can be bound with more than one VLAN or one combination of inner VLAN and outer VLAN. A VLAN or a combination of inner VLAN and outer VLAN can be bound with only one NAS-ID. If you configure multiple bindings for the same VLAN, the most recent configuration takes effect. To configure a NAS-ID profile: 70

87 2. Create a NAS-ID profile and enter NAS-ID profile view. aaa nas-id profile profile-name By default, no NAS-ID profiles exist. 3. Configure a NAS-ID and VLAN binding in the profile. nas-id nas-identifier bind { { c-vid vlan-id s-vid vlan-id } * vlan vlan-id } By default, no NAS-ID and VLAN bindings exist. In a QinQ network, specify an inner VLAN ID, outer VLAN ID, or both in a binding as a best practice. In a non-qinq network, you can only specify a VLAN ID in a binding by specifying the vlan vlan-id option. Setting the NAS-ID on an interface The NAS-ID on an interface is applicable only to portal, PPP, and IPoE users that access the network through the interface. If you set a NAS-ID on an interface and specify a NAS-ID profile for the interface, the NAS and VLAN binding in the NAS-ID profile has higher priority. To set the NAS-ID on an interface: 2. Enter Layer 3 interface view. 3. Set the NAS-ID on the interface. interface interface-type interface-number Specify a NAS-ID on the interface: aaa nas-id nas-identifier Specify a NAS-ID profile for the interface: aaa nas-id-profile profile-name N/A By default, no NAS-ID or NAS-ID profile is specified on an interface. The NAS-ID on an interface is the device name (set by using the sysname command). For portal users on an interface, the NAS-ID profile specified by using the portal nas-id-profile command takes precedence over the NAS-ID profile specified by using the aaa nas-id-profile command. For more information about the portal nas-id-profile command, see BRAS Services Command Reference. Setting the NAS-ID in an ISP domain 2. Enter ISP domain view domain isp-domain N/A 71

88 3. Set the NAS-ID in the ISP domain. nas-id nas-identifier By default, no NAS-ID is set in an ISP domain. Configuring the device ID 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. To configure the device ID: 2. Configure the device ID. aaa device-id device-id By default, the device ID is 0. AAA configuration examples Example: Configuring authentication and authorization for SSH users by a RADIUS server Network configuration As shown in Figure 15, configure the router 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 default user role network-operator to SSH users after they pass authentication. The RADIUS server runs on IMC. Add an account with username hello@bbb on the RADIUS server. The RADIUS server and the router use expert as the shared key for secure RADIUS communication. The ports for authentication and accounting are 1812 and 1813, respectively. Figure 15 Network diagram Procedure 1. Configure the RADIUS server on IMC 5.0: 72

89 NOTE: In this example, the RADIUS server runs on IMC PLAT 5.0 (E0101) and IMC UAM 5.0 (E0101). # Add the router to the IMC Platform as an access device: Log in to IMC, click the Service tab, and select User Access Manager > Access Device Management > Access Device from the navigation tree. Then, click Add to configure an access device as follows: a. Set the shared key for secure RADIUS communication to expert. b. Set the ports for authentication and accounting to 1812 and 1813, respectively. c. Select Device Management Service from the Service Type list. d. Select H3C from the Access Device Type list. e. Select an access device from the device list or manually add an access device. In this example, the device IP address is 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 router. The source IP address is chosen in the following order on the router: 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). Figure 16 Adding the router as an access device # Add an account for device management: Click the User tab, and select Access User View > Device Mgmt 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 Service Type list. c. Specify to as the IP address range of the hosts to be managed. d. Click OK. NOTE: The IP address range must contain the IP address of the router. 73

90 Figure 17 Adding an account for device management 2. Configure the router: # Configure the IP addresses for interfaces. (Details not shown.) # Create local RSA and DSA key pairs. <Router> system-view [Router] public-key local create rsa [Router] public-key local create dsa # Enable the SSH service. [Router] ssh server enable # Enable scheme authentication for user lines VTY 0 through VTY 63. [Router] line vty 0 63 [Router-line-vty0-63] authentication-mode scheme [Router-line-vty0-63] quit # Enable the default user role feature to assign authenticated SSH users the default user role network-operator. [Router] role default-role enable # Create a RADIUS scheme. [Router] radius scheme rad # Specify the primary authentication server. [Router-radius-rad] primary authentication # Set the shared key to expert in plaintext form for secure communication with the server. [Router-radius-rad] key authentication simple expert # Include domain names in the usernames sent to the RADIUS server. [Router-radius-rad] user-name-format with-domain 74

91 [Router-radius-rad] quit # Create an ISP domain named bbb and configure authentication, authorization, and accounting methods for login users. Because RADIUS user authorization information is piggybacked in authentication responses, the authentication and authorization methods must use the same RADIUS scheme. [Router] domain bbb [Router-isp-bbb] authentication login radius-scheme rad [Router-isp-bbb] authorization login radius-scheme rad [Router-isp-bbb] accounting login none [Router-isp-bbb] quit Verifying the configuration # Initiate an SSH connection to the router, and enter username hello@bbb and the correct password. The user logs in to the router. (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 and authorization for SSH users Network configuration As shown in Figure 18, configure the router to meet the following requirements: Perform local authentication and authorization for SSH users. Assign the network-admin user role to SSH users after they pass authentication. Figure 18 Network diagram Procedure # Configure IP addresses for interfaces. (Details not shown.) # Create local RSA and DSA key pairs. <Router> system-view [Router] public-key local create rsa [Router] public-key local create dsa # Enable the SSH service. [Router] ssh server enable # Enable scheme authentication for user lines VTY 0 through VTY 63. [Router] line vty 0 63 [Router-line-vty0-63] authentication-mode scheme [Router-line-vty0-63] quit # Create a device management user. [Router] local-user ssh class manage # Assign the SSH service to the local user. [Router-luser-manage-ssh] service-type ssh 75

92 # Set the password to TESTplat&! in plaintext form for the local user. [Router-luser-manage-ssh] password simple TESTplat&! # Specify the user role for the user as network-admin. [Router-luser-manage-ssh] authorization-attribute user-role network-admin [Router-luser-manage-ssh] quit # Create an ISP domain named bbb and configure the domain to use local authentication and authorization for login users. [Router] domain bbb [Router-isp-bbb] authentication login local [Router-isp-bbb] authorization login local [Router-isp-bbb] quit Verifying the configuration # Initiate an SSH connection to the router, and enter username ssh@bbb and the correct password. The user logs in to the router. (Details not shown.) # Verify that the user can use the commands permitted by the network-admin user role. (Details not shown.) Example: Configuring AAA for SSH users by an HWTACACS server Network configuration As shown in Figure 19, configure the router 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. Figure 19 Network diagram Procedure 1. Configure the HWTACACS server: # Set the shared keys to expert for secure communication with the router. (Details not shown.) # Add an account for the SSH user and specify the password. (Details not shown.) 2. Configure the router: # Configure IP addresses for interfaces. (Details not shown.) # Create an HWTACACS scheme. 76

93 <Router> system-view [Router] hwtacacs scheme hwtac # Specify the primary authentication server. [Router-hwtacacs-hwtac] primary authentication # Specify the primary authorization server. [Router-hwtacacs-hwtac] primary authorization # Specify the primary accounting server. [Router-hwtacacs-hwtac] primary accounting # Set the shared keys to expert in plaintext form for secure HWTACACS communication. [Router-hwtacacs-hwtac] key authentication simple expert [Router-hwtacacs-hwtac] key authorization simple expert [Router-hwtacacs-hwtac] key accounting simple expert # Exclude domain names from the usernames sent to the HWTACACS server. [Router-hwtacacs-hwtac] user-name-format without-domain [Router-hwtacacs-hwtac] quit # Create an ISP domain and configure the domain to use the HWTACACS scheme for authentication, authorization, and accounting of login users. [Router] domain bbb [Router-isp-bbb] authentication login hwtacacs-scheme hwtac [Router-isp-bbb] authorization login hwtacacs-scheme hwtac [Router-isp-bbb] accounting login hwtacacs-scheme hwtac [Router-isp-bbb] quit # Create local RSA and DSA key pairs. [Router] public-key local create rsa [Router] public-key local create dsa # Enable the SSH service. [Router] ssh server enable # Enable the default user role feature to assign authenticated SSH users the default user role network-operator. [Router] role default-role enable # Enable scheme authentication for user lines VTY 0 through VTY 63. [Router] line vty 0 63 [Router-line-vty0-63] authentication-mode scheme [Router-line-vty0-63] quit Verifying the configuration # Initiate an SSH connection to the router, and enter the correct username and password. The user logs in to the router. (Details not shown.) # Verify that the user can use the commands permitted by the network-operator user role. (Details not shown.) Example: Configuring authentication for SSH users by an LDAP server Network configuration As shown in Figure 20, an LDAP server is located at /24 and uses domain ldap.com. Configure the router to meet the following requirements: 77

94 Use the LDAP server to authenticate SSH users. Assign the default user role network-operator 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! Figure 20 Network diagram Procedure 1. Configure the LDAP server: NOTE: In this example, the LDAP server runs Microsoft Windows 2003 Server Active Directory. # 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. 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 21 Adding user aaa 78

95 f. In the dialog box, enter password ldap!123456, select options as needed, and click Next. Figure 22 Setting the user's password g. Click OK. # 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. 79

96 Figure 23 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 24 Adding user aaa to group Users # 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.) 2. Configure the router: # Configure IP addresses for interfaces. (Details not shown.) 80

97 # Create the local DSA key pair and RSA key pairs. <Router> system-view [Router] public-key local create dsa [Router] public-key local create rsa # Enable the SSH service. [Router] ssh server enable # Enable scheme authentication for user lines VTY 0 through VTY 63. [Router] line vty 0 63 [Router-line-vty0-63] authentication-mode scheme [Router-line-vty0-63] quit # Enable the default user role feature to assign authenticated SSH users the default user role network-operator. [Router] role default-role enable # Configure an LDAP server. [Router] ldap server ldap1 # Specify the IP address of the LDAP authentication server. [Router-ldap-server-ldap1] ip # Specify the administrator DN. [Router-ldap-server-ldap1] login-dn cn=administrator,cn=users,dc=ldap,dc=com # Specify the administrator password. [Router-ldap-server-ldap1] login-password simple admin! # Configure the base DN for user search. [Router-ldap-server-ldap1] search-base-dn dc=ldap,dc=com [Router-ldap-server-ldap1] quit # Create an LDAP scheme. [Router] ldap scheme ldap1-shml # Specify the LDAP authentication server. [Router-ldap-ldap-shml] authentication-server ldap1 [Router-ldap-ldap1-shml] quit # Create an ISP domain named bbb and configure the authentication, authorization, and accounting methods for login users. [Router] domain bbb [Router-isp-bbb] authentication login ldap-scheme ldap1-shml [Router-isp-bbb] authorization login none [Router-isp-bbb] accounting login none [Router-isp-bbb] quit Verifying the configuration # Initiate an SSH connection to the router, and enter username aaa@bbb and password ldap! The user logs in to the router. (Details not shown.) # Verify that the user can use the commands permitted by the network-operator user role. (Details not shown.) 81

98 Example: Configuring AAA for PPP users by an HWTACACS server Network configuration As shown in Figure 25: Router A uses the HWTACACS server to perform PAP authentication for users from Router B. The HWTACACS server is also the authorization server and accounting server of Router B. Router B does not provide authentication, authorization, or accounting for users from Router A. Figure 25 Network diagram Procedure 1. Configure the HWTACACS server (details not shown): a. Set the shared keys for secure communication with Router A to expert. b. Add user account userb for the PPP users from Router B. c. Specify the password as passb. 2. Configure Router A: # Configure IP addresses for interfaces. (Details not shown.) # Create an HWTACACS scheme. <RouterA> system-view [RouterA] hwtacacs scheme hwtac # Configure the primary HWTACACS server at Set the authentication, authorization, and accounting ports to 49. Configure the router to establish only one TCP connection with the server. [RouterA-hwtacacs-hwtac] primary authentication single-connection [RouterA-hwtacacs-hwtac] primary authorization single-connection [RouterA-hwtacacs-hwtac] primary accounting single-connection # Set the shared keys to expert in plaintext form for authentication, authorization, and accounting. [RouterA-hwtacacs-hwtac] key authentication simple expert [RouterA-hwtacacs-hwtac] key authorization simple expert [RouterA-hwtacacs-hwtac] key accounting simple expert # Exclude domain names from the usernames sent to the HWTACACS server. [RouterA-hwtacacs-hwtac] user-name-format without-domain [RouterA-hwtacacs-hwtac] quit # Create an ISP domain named bbb and configure the domain to use the HWTACACS scheme for authentication, authorization, and accounting for PPP users. 82

99 [RouterA] domain bbb [RouterA-isp-bbb] authentication ppp hwtacacs-scheme hwtac [RouterA-isp-bbb] authorization ppp hwtacacs-scheme hwtac [RouterA-isp-bbb] accounting ppp hwtacacs-scheme hwtac [RouterA-isp-bbb] quit # Enable PPP encapsulation on Serial 2/1/0/1:0. [RouterA] interface serial 2/1/0/1:0 [RouterA-Serial2/1/0/1:0] link-protocol ppp # Configure Serial 2/1/0/1:0 to authenticate the peer by using PAP in authentication domain bbb. [RouterA-Serial2/1/0/1:0] ppp authentication-mode pap domain bbb 3. Configure Router B: # Configure IP addresses for interfaces. (Details not shown.) # Enable PPP encapsulation on Serial 2/1/0/1:0. <RouterB> system-view [RouterB] interface serial 2/1/0/1:0 [RouterB-Serial2/1/0/1:0] link-protocol ppp # Configure the local username and password for PAP authentication to userb and plaintext passb, respectively. [RouterB-Serial2/1/0/1:0] ppp pap local-user userb password simple passb Verifying the configuration # Use the display interface serial command to display information for Serial 2/1/0/1:0. The PPP link is established if the output contains the following information: Both the physical layer and link layer are up. LCP and IPCP have entered the Opened state. Router A and Router B can ping each other. Troubleshooting RADIUS 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: 83

100 The NAS and the RADIUS server can ping each other. The username is in the 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 H3C Support. RADIUS packet delivery failure Symptom Analysis RADIUS packets cannot reach the RADIUS server. Possible reasons include: A communication failure exists between the NAS and the RADIUS server. 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 H3C 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. 84

101 The accounting server IP address is correctly configured on the NAS. 2. If the problem persists, contact H3C Support. Troubleshooting HWTACACS Similar to RADIUS troubleshooting. See "Troubleshooting RADIUS." Troubleshooting LDAP LDAP authentication failure Symptom Analysis User authentication fails. Possible reasons include: A communication failure exists between the NAS and the LDAP server. 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 H3C Support. 85

102 Appendixes Appendix A Commonly used RADIUS attributes Commonly used RADIUS attributes are defined in RFC 2865, RFC 2866, RFC 2867, and RFC Table 5 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) 11 Filter-ID 55 Event-Timestamp 12 Framed-MTU (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 86

103 No. Attribute No. Attribute 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 Appendix B Descriptions for commonly used standard RADIUS attributes No. Attribute Description 1 User-Name Name of the user to be authenticated. 2 User-Password 3 CHAP-Password 4 NAS-IP-Address User password for PAP authentication, only present in Access-Request packets when PAP authentication is used. Digest of the user password for CHAP authentication, only present in Access-Request packets when CHAP authentication is used. IP address for the server to use to identify the client. Typically, a client 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. 6 Service-Type Type of service that the user has requested or type of service to be provided. 7 Framed-Protocol Encapsulation protocol for framed access. 8 Framed-IP-Address IP address assigned to the user. 11 Filter-ID Name of the filter list. 12 Framed-MTU MTU for the data link between the user and NAS. For example, this 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. 18 Reply-Message Text to be displayed to the user, which can be used by the server to communicate information, for example, the authentication failure reason. 87

104 No. Attribute 26 Vendor-Specific 27 Session-Timeout 28 Idle-Timeout 31 Calling-Station-Id Description Vendor-specific proprietary attribute. A packet can contain one or more proprietary attributes, each of which can contain one or more subattributes. Maximum service duration for the user before termination of the session. Maximum idle time permitted for the user before termination of the session. User identification that the NAS sends to the server. For the LAN access service provided by an H3C 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. 40 Acct-Status-Type 45 Acct-Authentic 60 CHAP-Challenge 61 NAS-Port-Type 64 Tunnel-Type 65 Tunnel-Medium-Type 79 EAP-Message Type of the Accounting-Request packet. Possible values include: 1 Start. 2 Stop. 3 Interim-Update. 4 Reset-Charge. 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. 2 Local. 3 Remote. CHAP challenge generated by the NAS for MD5 calculation during 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.) 19 WLAN-IEEE 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. 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. 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 authentication. 88

105 No. Attribute 80 Message-Authenticator 81 Tunnel-Private-Group-ID Description Used for authentication and verification of authentication packets to 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 VLAN IDs by using this attribute. 87 NAS-Port-Id String for describing the port of the NAS that is authenticating the user. Appendix C RADIUS subattributes (vendor ID 25506) Table 6 lists all RADIUS subattributes with a vendor ID of Support for these subattributes depends on the device model. Table 6 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. 15 Remanent_Volume Total amount of data available for the connection, in different units for different server types. 17 ISP-ID ISP domain where the user obtains authorization information. 20 Command 25 Result_Code Operation for the session, used for session control. Possible values include: 1 Trigger-Request. 2 Terminate-Request. 3 SetPolicy. 4 Result. 5 PortalClear. Result of the Trigger-Request or SetPolicy operation, zero for success and any other value for failure. 26 Connect_ID Index of the user connection. 27 PortalURL PADM redirect URL assigned to PPPoE users. 28 Ftp_Directory FTP, SFTP, or SCP user working 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. 32 NAT-IP-Address 33 NAT-Start-Port Public IP address assigned to the user when the source IP address and port are translated. Start port number of the port range assigned to the user when the source IP address and port are translated. 89

106 No. Subattribute Description 34 NAT-End-Port End port number of the port range assigned to the user when the source IP address and port are translated. 59 NAS_Startup_Timestamp 60 Ip_Host_Addr 61 User_Notify 62 User_HeartBeat 98 Multicast_Receive_Group 100 IP6_Multicast_Receive_Group 101 MLD-Access-Limit Startup time of the NAS in seconds, which is represented by the time elapsed after 00:00:00 on Jan. 1, 1970 (UTC). User IP address and MAC address included in authentication and 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 transparently. 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 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 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 multicast packet to indicate that the user belongs to multiple multicast groups. Maximum number of MLD multicast groups that the user can join concurrently. 102 local-name L2TP local tunnel name. 103 IGMP-Access-Limit Maximum number of IGMP multicast groups that the user can join concurrently. 104 VPN-Instance MPLS L3VPN instance to which a user belongs. 105 ANCP-Profile ANCP profile name. 106 Up-Priority User priority of incoming packets. 107 Down-Priority User priority of outgoing packets. 135 Client-Primary-DNS IP address of the primary DNS server. 136 Client-Secondary-DNS IP address of the secondary DNS server. 140 User_Group 144 Acct_IPv6_Input_Octets 145 Acct_IPv6_Output_Octets 146 Acct_IPv6_Input_Packets 147 Acct_IPv6_Output_Packets 148 Acct_IPv6_Input_Gigawords User groups assigned after the SSL VPN user passes authentication. A user can belong to multiple user groups that are separated by semicolons. This attribute is used to work with the SSL VPN device. Bytes of IPv6 packets in the inbound direction. The measurement unit depends on the configuration on the device. Bytes of IPv6 packets in the outbound direction. The measurement unit depends on the configuration on the device. Number of IPv6 packets in the inbound direction. The measurement unit depends on the configuration on the device. Number of IPv6 packets in the outbound direction. The measurement unit depends on the configuration on the device. Bytes of IPv6 packets in the inbound direction. The measurement unit is 4G bytes. 90

107 No. Subattribute Description 149 Acct_IPv6_Output_Gigawords Bytes of IPv6 packets in the outbound direction. The measurement unit is 4G bytes. 155 User-Roles List of space-separated user roles. 210 Av-Pair User-defined attribute pair. Available attribute pairs include: Server-assigned dynamic WEP key in the format of leap:session-key=xxx. Server-assigned voice VLAN in the format of device-traffic-class=voice. Server-assigned user role in the format of shell:role=xxx. 215 Accounting-Level ITA traffic level in the range of 1 to Ita-Policy ITA policy name. 230 Nas-Port Interface through which the user is connected to the NAS. 246 Auth_Detail_Result 247 Input-Committed-Burst-Size 248 Output-Committed-Burst-Size 249 authentication-type 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 redirects it to the URL specified by subattribute 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. 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. This subattribute must be assigned together with the Output-Average-Rate attribute. Authentication type. The value can be: 1 Intranet access authentication. 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. 91

108 Configuring ANCP About ANCP Access Node Control Protocol (ANCP) is an extension of the General Switch Management Protocol version 3 (GSMPv3). It exchanges control messages between a Broadband Remote Access Server (BRAS) and an Access Node (AN). ANCP is a TCP-based client/server protocol. Comware only supports the ANCP server. How ANCP works As shown in Figure 26, the ANCP client runs on a DSLAM (an AN), and the ANCP server runs on a BRAS (an H3C device). Access loops are digital subscriber lines (DSLs). Figure 26 ANCP network diagram ANCP works between the DSLAM and the BRAS as follows: 1. The ANCP client establishes a TCP connection to the ANCP server on port The client and server establish an ANCP adjacency and complete ANCP negotiation: a. The client and the server send each other a SYN message. The SYN message contains the version number, adjacency timer, sender MAC address, and the capabilities that the sender supports. The BRAS can only use its bridge MAC as the sender MAC address. By default, the DSLAM uses its bridge MAC as the sender MAC address. Its sender MAC address is configurable. ANCP retransmits the SYN message if it does not receive the SYN message from its peer before the proposed adjacency timer expires. If SYN retransmission attempts exceed the limit, ANCP terminates the TCP connection. b. The client and the server send each other a SYNACK message that contains negotiated values. The negotiated values include the longer adjacency timer and the capabilities supported by both ends. 92

109 The capabilities supported by the ANCP server include dynamic topology discovery, DSL service profile assignment, and DSL OAM. The two ends cannot establish an adjacency if they use different version numbers. ANCP retransmits the SYNACK message if it does not receive the SYNACK message from its peer before the negotiated adjacency timer expires. If SYNACK retransmission attempts exceed the limit, ANCP terminates the TCP connection. c. The server and the client send each other an ACK message to establish an ANCP adjacency. ANCP retransmits the ACK message if it does not receive the ACK message from its peer before the negotiated adjacency timer expires. If one end does not receive an ACK message from its peer within three intervals, it sends a RSTACK message to terminate the TCP connection. 3. ANCP performs the following functions: ANCP adjacency maintenance The client and the server periodically send ACK messages at the interval set by the negotiated adjacency timer. If one end does not receive an ACK message from its peer within three intervals, it sends a RSTACK message to terminate the TCP connection. Dynamic topology discovery The client sends information about active DSLs to the BRAS. The information includes DSL status, and the actual and maximum uplink and downlink rates. When an active DSL has a state or parameter change, the client notifies the server about the change. The server uses the DSL information to avoid congestion on the access network. Service profile assignment The RADIUS server assigns a service profile to the ANCP server when a user accesses the network or customizes services through a DSL. The ANCP server sends the service profile to the ANCP client. The ANCP client applies the service profile to the DSL. The ANCP server uses a DSL ID in the DHCP Option 82 or PPPoE+ message from the ANCP client to identify a DSL. DSL OAM The ANCP server sends a message to the ANCP client for DSL OAM. The ANCP client performs loopback detection on the specified DSL and sends the result to the ANCP server. Protocols and standards RFC 3292: GSMPv3 RFC 6320: Protocol for Access Node Control Mechanism in Broadband Networks ANCP tasks at a glance Tasks at a glance (Required.) Enabling the ANCP server (Required.) Configuring the adjacency timer (Required.) Configuring the maximum number of retransmission attempts (Required.) Creating an ANCP neighbor (Required.) Configuring an ANCP neighbor ID Remarks N/A N/A N/A N/A N/A 93

110 Tasks at a glance (Required.) Configuring a source interface for a neighbor Configuring the global source interface in system view Configuring a source interface for a neighbor in neighbor view (Required.) Configuring the DSL entry aging time (Optional.) Configuring ANCP OAM (Optional.) Assigning a service profile to a DSL Remarks You must configure one global source interface for all adjacencies or one neighbor-specific source interface for each adjacency. N/A N/A N/A Enabling the ANCP server You must enable the ANCP server. If the ANCP server is disabled, the system terminates all ANCP adjacencies and closes TCP port To enable the ANCP server: 2. Enable the ANCP server. ancp enable By default, the ANCP server is disabled. Configuring the adjacency timer The ANCP server and the ANCP client exchange SYN packets to negotiate adjacency timers. The two ends use the longer adjacency timer to send SYNACK and ACK packets. To configure the adjacency timer: 2. Configure the adjacency timer. ancp session interval interval The default adjacency timer is 25 seconds. Configuring the maximum number of retransmission attempts The ANCP server retransmits a SYN or SYNACK message if it does not receive the message from its peer before the adjacency timer expires. If the peer does not respond after the retransmission attempts reach the maximum, the server closes the TCP connection. To configure the maximum number of retransmission attempts: 2. Configure the maximum number of retransmission attempts. ancp session retransmit retransmit-value By default, the maximum number of retransmission attempts is

111 Creating an ANCP neighbor ANCP clients are the ANCP neighbors of the ANCP server. You can create multiple ANCP neighbors and configure parameters for each neighbor. To create an ANCP neighbor: 2. Create an ANCP neighbor and enter its view. ancp neighbor neighbor-name By default, no ANCP neighbor exists. Configuring an ANCP neighbor ID About ANCP neighbor IDs The ANCP server uses ANCP neighbor IDs to identify ANCP clients. If the MAC address of a client does not match any ANCP neighbor ID, the server closes the TCP connection to the client. Restrictions and guidelines Procedure When you configure an ANCP neighbor ID, follow these restrictions and guidelines: A neighbor ID uniquely identifies an ANCP neighbor. If you remove a neighbor ID, the server closes the TCP connection to the corresponding neighbor. To configure an ANCP neighbor ID: 2. Enter ANCP neighbor view. ancp neighbor neighbor-name N/A 3. Configure an ANCP neighbor ID. peer-id peer-id By default, no ANCP neighbor ID exists. Configuring a source interface for a neighbor About the sources interface for a neighbor A neighbor-specific source interface must be a loopback interface. The ANCP server uses one of the following addresses as the source IP address for TCP packets sent to an ANCP neighbor: The primary IPv4 address of the source interface. The first IPv6 global unicast address of the source interface. 95

112 Restrictions and guidelines for the source interface of a neighbor When you configure a source interface for a neighbor, follow these restrictions and guidelines: The ANCP server prefers the neighbor-specific source interface over the global source interface when it communicates with the neighbor. If you delete a neighbor-specific source interface, and no global source interface exists, the device closes TCP port 6068 for the neighbor. If you change the source interface, the device uses the IP address of the new source interface. The delete or change operation does not affect existing TCP connections. Configuring the global source interface in system view 2. Configure the global source interface. ancp source-interface loopback interface-number By default, no global source interface exists. Configuring a source interface for a neighbor in neighbor view 2. Enter ANCP neighbor view. ancp neighbor neighbor-name N/A 3. Configure a source interface for a neighbor. source-interface loopback interface-number By default, no source interface is configured for a neighbor. Configuring the DSL entry aging time The server records DSL information in DSL entries. If a user on a DSL goes offline, the server will remove the corresponding DSL entry when its aging timer expires. If an ANCP neighbor needs to reboot the DSL after receiving a service profile, the DSL entry aging time configured for the neighbor must be long enough for the neighbor to complete the reboot. To configure the DSL entry aging time: 2. Enter ANCP neighbor view. ancp neighbor neighbor-name N/A 3. Configure the DSL entry aging time. aging-time value The default aging time is 150 seconds. 96

113 Configuring ANCP OAM You can start an OAM test for a DSL to monitor the status of the DSL. To start an ANCP OAM test for a DSL: Step Command 1. Enter system view. system-view 2. Start an ANCP OAM test for a DSL. ancp oam [ count test-counter timeout time-value ] * access-loop circuit-id Assigning a service profile to a DSL The ANCP server can convey service profiles received from the RADIUS server to clients. You can also manually assign a service profile to a DSL from the server. The service profile must already exist on the client. To assign a service profile to a DSL: Step Command 1. Enter system view. system-view 2. Assign a service profile to a DSL. ancp access-loop-configure circuit-id circuit-id service-profile profile-name [ timeout time-value ] Display and maintenance commands for ANCP Execute display commands in any view and reset command in user view. Task Command Display information about ANCP neighbors. display ancp neighbor [ neighbor-name ] Display information about DSL entries. display ancp access-loop [ circuit-id circuit-id neighbor neighbor-name ] Display ANCP neighbor statistics. display ancp statistic [ neighbor neighbor-name ] Clear ANCP neighbor information and close TCP connections. Delete DSL entries. reset ancp neighbor [ neighbor-name ] reset ancp access-loop [ circuit-id circuit-id neighbor neighbor-name ] Clear ANCP neighbor statistics. reset ancp statistic [ neighbor neighbor-name ] 97

114 ANCP configuration examples Example: Configuring ANCP Network configuration As shown in Figure 27, users access the network through IPoE or PPPoE. The RADIUS server performs user authentication and accounting. Configure ANCP to achieve the following purposes: The BRAS can dynamically discover DSLs on the DSLAM. The BRAS can configure DSLs. The BRAS can perform OAM tests on DSLs. Figure 27 Network diagram Procedure # Configure the DSLAM so it can reach interface loopback 1 on the BRAS. (Details not shown.) # Enable the ANCP client on the DSLAM. (Details not shown.) # Enable the ANCP server on the BRAS. <BRAS> system-view [BRAS] ancp enable # Create an ANCP neighbor. [BRAS] ancp neighbor test1 # Configure an ANCP neighbor ID. [BRAS-ancp-neighbor-test1] peer-id [BRAS-ancp-neighbor-test1] quit # Configure the source interface for the ANCP neighbor. [BRAS] interface loopback 1 [BRAS-LoopBack1] ip address [BRAS-LoopBack1] quit [BRAS] ancp neighbor test1 98

115 [BRAS-ancp-neighbor-test1] source-interface loopback 1 # Configure the DSL entry aging time as 100 seconds. [BRAS-ancp-neighbor-test1] aging-time 100 [BRAS-ancp-neighbor-test1] quit Verifying the configuration # Verify that the BRAS and the DSLAM have established an ANCP adjacency. [BRAS] display ancp neighbor test1 Neighbor name : test1 Peer ID : Source interface : LoopBack1 Session message interval : 25 s Session message retransmit : 10 Aging time : 100 s State : used Peer IP : Peer port : 510 Neighbor capacities : discovery, line-cfg, oam Negotiated interval : 25.0 s Access loop number : 3 # Verify that the BRAS has created DSL entries. [BRAS] display ancp access-loop Total entries: 3 Neighbor name Peer ID Circuit ID State test Access1 UP test Access2 UP test Access3 UP [BRAS] display ancp access-loop circuit-id Access1 Neighbor name : test1 Circuit ID : Access1 Remote ID : remote3 Peer ID : DSL type : ADSL1 Actual data rate upstream : 512 Kbps Actual data rate downstream : 1536 Kbps Min data rate upstream : 32 Kbps Min data rate downstream : 32 Kbps Attainable data rate upstream : 96 Kbps Attainable data rate downstream : 96 Kbps Max data rate upstream : 64 Kbps Max data rate downstream : Kbps Min low power data rate upstream : 0 Kbps Min low power data rate downstream : 0 Kbps Max delay upstream : 6 s Max delay downstream : 16 s Actual delay upstream : 4 s Actual delay downstream : 16 s Data link : ETHERNET 99

116 Encapsulation 1 : Untagged Ethernet Encapsulation 2 : NA # Verify that the BRAS can successfully assign a service profile. [BRAS] ancp access-loop-configure circuit-id Access1 service-profile profile1 timeout 10 Issuing service profile name profile1 for Access1. Please wait Issued the service profile name successfully. # Verify that the BRAS can successfully start an OAM test on a DSL. [BRAS] ancp oam count 5 timeout 5 access-loop Access1 OAM testing Access1. Please wait OAM test succeeded. 100

117 DHCP overview DHCP network model The Dynamic Host Configuration Protocol (DHCP) provides a framework to assign configuration information to network devices. Figure 28 shows a typical DHCP application scenario where the DHCP clients and the DHCP server reside on the same subnet. The DHCP clients can also obtain configuration parameters from a DHCP server on another subnet through a DHCP relay agent. For more information about the DHCP relay agent, see "Configuring the DHCP relay agent." Figure 28 A typical DHCP application DHCP address allocation Allocation mechanisms DHCP supports the following allocation mechanisms: Static allocation The network administrator assigns an IP address to a client, such as a WWW server, and DHCP conveys the assigned address to the client. Automatic allocation DHCP assigns a permanent IP address to a client. Dynamic allocation DHCP assigns an IP address to a client for a limited period of time, which is called a lease. Most DHCP clients obtain their addresses in this way. 101

118 IP address allocation process Figure 29 IP address allocation process As shown in Figure 29, a DHCP server assigns an IP address to a DHCP client in the following process: 1. The client broadcasts a DHCP-DISCOVER message to locate a DHCP server. 2. Each DHCP server offers configuration parameters such as an IP address to the client in a DHCP-OFFER message. The sending mode of the DHCP-OFFER is determined by the flag field in the DHCP-DISCOVER message. For more information, see "DHCP message format." 3. If the client receives multiple offers, it accepts the first received offer, and broadcasts it in a DHCP-REQUEST message to formally request the IP address. (IP addresses offered by other DHCP servers can be assigned to other clients.) 4. All DHCP servers receive the DHCP-REQUEST message. However, only the server selected by the client does one of the following operations: Returns a DHCP-ACK message to confirm that the IP address has been allocated to the client. Returns a DHCP-NAK message to deny the IP address allocation. After receiving the DHCP-ACK message, the client verifies the following details before using the assigned IP address: The assigned IP address is not in use. To verify this, the client broadcasts a gratuitous ARP packet. The assigned IP address is not in use if no response is received within the specified time. The assigned IP address is not on the same subnet as any IP address in use on the client. Otherwise, the client sends a DHCP-DECLINE message to the server to request an IP address again. IP address lease extension A dynamically assigned IP address has a lease. When the lease expires, the IP address is reclaimed by the DHCP server. To continue using the IP address, the client must extend the lease duration. When about half of the lease duration elapses, the DHCP client unicasts a DHCP-REQUEST to the DHCP server to extend the lease. Depending on the availability of the IP address, the DHCP server returns one of the following messages: A DHCP-ACK unicast confirming that the client's lease duration has been extended. A DHCP-NAK unicast denying the request. 102

119 If the client receives no reply, it broadcasts another DHCP-REQUEST message for lease extension when about seven-eighths of the lease duration elapses. Again, depending on the availability of the IP address, the DHCP server returns either a DHCP-ACK unicast or a DHCP-NAK unicast. DHCP message format Figure 30 shows the DHCP message format. DHCP uses some of the fields in significantly different ways. The numbers in parentheses indicate the size of each field in bytes. Figure 30 DHCP message format op Message type defined in options field. 1 = REQUEST, 2 = REPLY htype, hlen Hardware address type and length of the DHCP client. hops Number of relay agents a request message traveled. xid Transaction ID, a random number chosen by the client to identify an IP address allocation. secs Filled in by the client, the number of seconds elapsed since the client began address acquisition or renewal process. This field is reserved and set to 0. flags The leftmost bit is defined as the BROADCAST (B) flag. If this flag is set to 0, the DHCP server sent a reply back by unicast. If this flag is set to 1, the DHCP server sent a reply back by broadcast. The remaining bits of the flags field are reserved for future use. ciaddr Client IP address if the client has an IP address that is valid and usable. Otherwise, set to zero. (The client does not use this field to request an IP address to lease.) yiaddr Your IP address. It is an IP address assigned by the DHCP server to the DHCP client. siaddr Server IP address, from which the client obtained configuration parameters. giaddr Gateway IP address. It is the IP address of the first relay agent to which a request message travels. chaddr Client hardware address. sname Server host name, from which the client obtained configuration parameters. file Boot file (also called system software image) name and path information, defined by the server to the client. options Optional parameters field that is variable in length. Optional parameters include the message type, lease duration, subnet mask, domain name server IP address, and WINS IP address. 103

120 DHCP options DHCP extends the message format as an extension to BOOTP for compatibility. DHCP uses the options field to carry information for dynamic address allocation and provide additional configuration information for clients. Figure 31 DHCP option format Common DHCP options The following are common DHCP options: Option 3 Router option. It specifies the gateway address to be assigned to the clients. Option 6 DNS server option. It specifies the DNS server IP address to be assigned to the clients. Option 33 Static route option. It specifies a list of classful static routes (the destination addresses in these static routes are classful) that a client should add into its routing table. If both Option 33 and Option 121 exist, Option 33 is ignored. Option 51 IP address lease option. Option 53 DHCP message type option. It identifies the type of the DHCP message. Option 55 Parameter request list option. It is used by a DHCP client to request specified configuration parameters. The option includes values that correspond to the parameters requested by the client. Option 60 Vendor class identifier option. A DHCP client uses this option to identify its vendor. A DHCP server uses this option to distinguish DHCP clients, and assigns IP addresses to them. Option 66 TFTP server name option. It specifies the TFTP server domain name to be assigned to the clients. Option 67 Boot file name option. It specifies the boot file name to be assigned to the client. Option 121 Classless route option. It specifies a list of classless static routes (the destination addresses in these static routes are classless) that a client should add into its routing table. If both Option 33 and Option 121 exist, Option 33 is ignored. Option 150 TFTP server IP address option. It specifies the TFTP server IP address to be assigned to the clients. For more information about DHCP options, see RFC 2132 and RFC Custom DHCP options Some options, such as Option 43, Option 82, and Option 184, have no standard definitions in RFC

121 Vendor-specific option (Option 43) Option 43 function DHCP servers and clients use Option 43 to exchange vendor-specific configuration information. The DHCP client can obtain the following information through Option 43: ACS parameters, including the ACS URL, username, and password. Service provider identifier, which is acquired by the CPE from the DHCP server and sent to the ACS for selecting vender-specific configurations and parameters. For more information about CPE and ACS, see Network Management and Monitoring Configuration Guide. PXE server address, which is used to obtain the boot file or other control information from the PXE server. AC address, which is used by an AP to obtain the boot file or other control information from the AC. Option 43 format Figure 32 Option 43 format Network configuration parameters are carried in different sub-options of Option 43 as shown in Figure 32. Sub-option type The field value can be 0x01 (ACS parameter sub-option), 0x02 (service provider identifier sub-option), or 0x80 (PXE server address sub-option). Sub-option length Excludes the sub-option type and sub-option length fields. Sub-option value The value format varies by sub-option. Sub-option value field format ACS parameter sub-option value field Includes the ACS URL, username, and password separated by spaces (hexadecimal number 20) as shown in Figure 33. Figure 33 ACS parameter sub-option value field Service provider identifier sub-option value field Includes the service provider identifier. PXE server address sub-option value field Includes the PXE server type that can only be 0, the server number that indicates the number of PXE servers contained in the sub-option, and server IP addresses, as shown in Figure

122 Figure 34 PXE server address sub-option value field Relay agent option (Option 82) Option 82 is the relay agent option. It records the location information about the DHCP client. When a DHCP relay agent or DHCP snooping device receives a client's request, it adds Option 82 to the request and sends it to the server. The administrator can use Option 82 to locate the DHCP client and further implement security control and accounting. The DHCP server can use Option 82 to provide individual configuration policies for the clients. Option 82 can include a maximum of 255 sub-options and must include a minimum of one sub-option. Option 82 supports two sub-options: sub-option 1 (Circuit ID) and sub-option 2 (Remote ID). Option 82 has no standard definition. Its padding formats vary by vendor. Circuit ID has the following padding modes: String padding mode Includes a character string specified by the user. Normal padding mode Includes the VLAN ID and interface number of the interface that receives the client's request. Verbose padding mode Includes the access node identifier specified by the user, and the VLAN ID, interface number and interface type of the interface that receives the client's request. Remote ID has the following padding modes: String padding mode Includes a character string specified by the user. Normal padding mode Includes the MAC address of the DHCP relay agent interface or the MAC address of the DHCP snooping device that receives the client's request. Sysname padding mode Includes the name of the device. To set the device name, use the sysname command in system view. Option 184 Option 184 is a reserved option. You can define the parameters in the option as needed. The device supports Option 184 carrying voice related parameters, so a DHCP client with voice functions can get voice parameters from the DHCP server. Option 184 has the following sub-options: Sub-option 1 Specifies the IP address of the primary network calling processor. The primary processor acts as the network calling control source and provides program download services. For Option 184, you must define sub-option 1 to make other sub-options take effect. Sub-option 2 Specifies the IP address of the backup network calling processor. DHCP clients contact the backup processor when the primary one is unreachable. Sub-option 3 Specifies the voice VLAN ID and the result whether the DHCP client takes this VLAN as the voice VLAN. 106

123 Sub-option 4 Specifies the failover route that includes the IP address and the number of the target user. A SIP VoIP user uses this IP address and number to directly establish a connection to the target SIP user when both the primary and backup calling processors are unreachable. Protocols and standards RFC 2131, Dynamic Host Configuration Protocol RFC 2132, DHCP Options and BOOTP Vendor Extensions RFC 1542, Clarifications and Extensions for the Bootstrap Protocol RFC 3046, DHCP Relay Agent Information Option RFC 3442, The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4 107

124 Configuring the DHCP server About DHCP server A DHCP server manages a pool of IP addresses and client configuration parameters. It selects an IP address and configuration parameters from the address pool and allocates them to a requesting DHCP client. DHCP address assignment mechanisms Configure the following address assignment mechanisms as needed: Static address allocation Manually bind the MAC address or ID of a client to an IP address in a DHCP address pool. When the client requests an IP address, the DHCP server assigns the IP address in the static binding to the client. Dynamic address allocation Specify IP address ranges in a DHCP address pool. Upon receiving a DHCP request, the DHCP server dynamically selects an IP address from the matching IP address range in the address pool. You can specify IP address ranges in an address pool by using either of the following methods: Method 1 A primary subnet being divided into multiple address ranges in an address pool Method 2 A primary subnet and multiple secondary subnets in an address pool A primary subnet being divided into multiple address ranges in an address pool An address range includes a common IP address range and IP address ranges for DHCP user classes. Upon receiving a DHCP request, the DHCP server finds a user class matching the client and selects an IP address in the address range of the user class for the client. A user class can include multiple matching rules, and a client matches the user class as long as it matches any of the rules. In address pool view, you can specify different address ranges for different user classes. The DHCP server selects an IP address for a client by performing the following steps: 1. DHCP server compares the client against DHCP user classes in the order they are configured. 2. If the client matches a user class, the DHCP server selects an IP address from the address range of the user class. 3. If the matching user class has no assignable addresses, the DHCP server compares the client against the next user class. If all the matching user classes have no assignable addresses, the DHCP server selects an IP address from the common address range. 4. If the DHCP client does not match any DHCP user class, the DHCP server selects an address in the IP address range specified by the address range command. If the address range has no assignable IP addresses or it is not configured, the address allocation fails. NOTE: All address ranges must belong to the primary subnet. If an address range does not reside on the primary subnet, DHCP cannot assign the addresses in the address range. A primary subnet and multiple secondary subnets in an address pool The DHCP server selects an IP address from the primary subnet first. If there is no assignable IP address on the primary subnet, the DHCP server selects an IP address from secondary subnets in the order they are configured. 108

125 Principles for selecting an address pool The DHCP server observes the following principles to select an address pool for a client: 1. If there is an address pool where an IP address is statically bound to the MAC address or ID of the client, the DHCP server selects this address pool and assigns the statically bound IP address and other configuration parameters to the client. 2. If the receiving interface has an address pool applied, the DHCP server selects an IP address and other configuration parameters from this address pool. 3. If the receiving interface has a DHCP policy and the DHCP client matches a user class, the DHCP server selects the address pool that is bound to the matching user class. If no matching user class is found, the server assigns an IP address and other parameters from the default DHCP address pool. If no default address pool is specified or the default address pool does not have assignable IP addresses, the address assignment fails. 4. If the above conditions are not met, the DHCP server selects an address pool depending on the client location. Client on the same subnet as the server The DHCP server compares the IP address of the receiving interface with the primary subnets of all address pools. If a match is found, the server selects the address pool with the longest-matching primary subnet. If no match is found, the DHCP server compares the IP address with the secondary subnets of all address pools. The server selects the address pool with the longest-matching secondary subnet. Client on a different subnet than the server The DHCP server compares the IP address in the giaddr field of the DHCP request with the primary subnets of all address pools. If a match is found, the server selects the address pool with the longest-matching primary subnet. If no match is found, the DHCP server compares the IP address with the secondary subnets of all address pools. The server selects the address pool with the longest-matching secondary subnet. For example, two address pools /24 and /25 are configured but not applied to any DHCP server's interfaces. If the IP address of the receiving interface is /25, the DHCP server selects the address pool /25. If the address pool has no available IP addresses, the DHCP server will not select the other pool and the address allocation will fail. If the IP address of the receiving interface is /25, the DHCP server selects the address pool /24. To ensure correct address allocation, keep the IP addresses used for dynamic allocation on one of the subnets: Clients on the same subnet as the server Subnet where the DHCP server receiving interface resides. Clients on a different subnet than the server Subnet where the first DHCP relay interface that faces the clients resides. NOTE: As a best practice, configure a minimum of one matching primary subnet in your network. Otherwise, the DHCP server selects only the first matching secondary subnet for address allocation. If the network has more DHCP clients than the assignable IP addresses in the secondary subnet, not all DHCP clients can obtain IP addresses. 109

126 IP address allocation sequence The DHCP server selects an IP address for a client in the following sequence: 1. IP address statically bound to the client's MAC address or ID. 2. IP address that was ever assigned to the client. 3. IP address designated by the Option 50 field in the DHCP-DISCOVER message sent by the client. Option 50 is the Requested IP Address option. The client uses this option to specify the wanted IP address in a DHCP-DISCOVER message. The content of Option 50 is user defined. 4. First assignable IP address found in the way discussed in "DHCP address assignment mechanisms" and "Principles for selecting an address pool." 5. IP address that was a conflict or passed its lease duration. If no IP address is assignable, the server does not respond. NOTE: If a client moves to another subnet, the DHCP server selects an IP address in the address pool matching the new subnet. It does not assign the IP address that was once assigned to the client. Conflicted IP addresses can be assigned to other DHCP clients only after the addresses are in conflict for an hour. DHCP server tasks at a glance Tasks at a glance (Optional.) Creating a DHCP user class (Required.) Configuring an address pool on the DHCP server (Required.) Enabling DHCP (Required.) Enabling the DHCP server on an interface (Optional.) Applying a DHCP address pool to a VPN instance (Optional.) Applying an address pool on an interface (Optional.) Configuring a DHCP policy for dynamic address assignment (Optional.) Allocating different IP addresses to DHCP clients with the same MAC (Optional.) Enabling random IP address allocation (Optional.) Configuring IP address conflict detection (Optional.) Enabling handling of Option 82 (Optional.) Disabling Option 60 encapsulation in DHCP replies (Optional.) Configuring the DHCP server security features (Optional.) Configuring DHCP server compatibility (Optional.) Setting the DSCP value for DHCP packets sent by the DHCP server (Optional.) Configuring DHCP packet rate limit on a DHCP server interface (Optional.) Configuring DHCP binding auto backup (Optional.) Binding gateways to DHCP server's MAC address (Optional.) Advertising subnets assigned to clients 110

127 Tasks at a glance (Optional.) Enabling client offline detection on the DHCP server (Optional.) Configuring SNMP notifications for the DHCP server (Optional.) Enabling DHCP logging on the DHCP server Creating a DHCP user class The DHCP server classifies DHCP users into different user classes according to the hardware address, option information, or the giaddr field in the received DHCP requests. The server allocates IP addresses and configuration parameters to DHCP clients in different user classes. To create a DHCP user class: 2. Create a DHCP user class and enter DHCP user class view. 3. Configure a match rule for the DHCP user class. dhcp class class-name if-match rule rule-number { hardware-address hardware-address mask hardware-address-mask option option-code [ ascii ascii-string [ offset offset partial ] hex hex-string [ mask mask offset offset length length partial ] ] relay-agent gateway-address } Required for client classification. By default, no DHCP user class exists. Required for client classification. By default, no match rule is configured for a DHCP user class. Configuring an address pool on the DHCP server DHCP address pool tasks at a glance Tasks at a glance (Required.) Creating a DHCP address pool Perform one or more of the following tasks: Specifying IP address ranges for a DHCP address pool Specifying gateways for DHCP clients Specifying a domain name suffix for DHCP clients Specifying DNS servers for DHCP clients Specifying WINS servers and NetBIOS node type for DHCP clients Specifying BIMS server for DHCP clients Specifying the configuration file for DHCP client auto-configuration Specifying a server for DHCP clients Configuring Option 184 parameters for DHCP clients Customizing DHCP options Configuring the DHCP user class whitelist 111

128 Creating a DHCP address pool 2. Create a DHCP address pool and enter its view. dhcp server ip-pool pool-name By default, no DHCP address pool exists. Specifying IP address ranges for a DHCP address pool You can configure both static and dynamic address allocation mechanisms in a DHCP address pool. For dynamic address allocation, you can specify either a primary subnet with multiple address ranges or a primary subnet with multiple secondary subnets for a DHCP address pool. You cannot configure both. Specifying a primary subnet and multiple address ranges for a DHCP address pool Some scenarios need to classify DHCP clients on the same subnet into different address groups. To meet this need, you can configure DHCP user classes and specify different address ranges for the classes. The clients matching a user class can then get the IP addresses of an address range. In addition, you can specify a common address range for the clients that do not match any user class. If no common address range is specified, such clients fail to obtain IP addresses. If there is no need to classify clients, you do not need to configure DHCP user classes or their address ranges. Follow these restrictions and guidelines when you specify a primary subnet and multiple address ranges for a DHCP address pool: If you execute the network or address range command multiple times for the same address pool, the most recent configuration takes effect. If you execute the forbidden-ip command multiple times, you exclude multiple address ranges from dynamic allocation. IP addresses specified by the forbidden-ip command are not assignable in the current address pool, but are assignable in other address pools. IP addresses specified by the dhcp server forbidden-ip command are not assignable in any address pool. You can use class range to modify an existing address range, and the new address range can include IP addresses that are being used by clients. Upon receiving a lease extension request for such an IP address, the DHCP server allocates a new IP address to the requesting client. But the original lease continues aging in the address pool, and will be released when the lease duration is reached. To release such lease without waiting for its timeout, execute the reset dhcp server ip-in-use command. To specify a primary subnet and multiple address ranges for a DHCP address pool: 2. Enter DHCP address pool view. 3. Specify the primary subnet for the address pool. 4. (Optional.) Specify the common address range. dhcp server ip-pool pool-name network network-address [ mask-length mask mask ] address range start-ip-address [ end-ip-address ] [ vpn-instance vpn-instance-name ] By default, no DHCP address pool exists. By default, no primary subnet is specified. By default, no IP address range is specified. 112

129 5. (Optional.) Specify an IP address range for a DHCP user class. class class-name range start-ip-address end-ip-address By default, no IP address range is specified for a user class. The DHCP user class must already exist. To specify address ranges for multiple DHCP user classes, repeat this step. 6. (Optional.) Set the address lease duration. 7. (Optional.) Exclude the specified IP addresses in the address pool from dynamic allocation. expired { allow-hint { day day [ hour hour [ minute minute [ second second ] ] ] unlimited } [ allow-hint ] } forbidden-ip ip-address&<1-8> The default setting is 1 day. By default, all the IP addresses in the DHCP address pool are assignable. 8. Return to system view. quit N/A 9. (Optional.) Exclude the specified IP addresses from automatic allocation globally. dhcp server forbidden-ip start-ip-address [ end-ip-address ] [ vpn-instance vpn-instance-name ] By default, except for the IP address of the DHCP server interface, all IP addresses in address pools are assignable. To exclude multiple IP address ranges, repeat this step. Specifying a primary subnet and multiple secondary subnets for a DHCP address pool If an address pool has a primary subnet and multiple secondary subnets, the server assigns IP addresses on a secondary subnet when the primary subnet has no assignable IP addresses. Follow these guidelines when you specify a primary subnet and secondary subnets for a DHCP address pool: You can specify only one primary subnet in each address pool. If you use the network command multiple times, the most recent configuration takes effect. You can specify a maximum of 32 secondary subnets in each address pool. IP addresses specified by the forbidden-ip command are not assignable in the current address pool, but are assignable in other address pools. IP addresses specified by the dhcp server forbidden-ip command are not assignable in any address pool. To specify a primary subnet and secondary subnets for a DHCP address pool: 2. Enter DHCP address pool view. dhcp server ip-pool pool-name By default, no DHCP address pool exists. 3. Specify the primary subnet. 4. (Optional.) Specify a secondary subnet. 5. (Optional.) Return to address pool view. network network-address [ mask-length mask mask ] network network-address [ mask-length mask mask ] secondary quit By default, no primary subnet is specified. By default, no secondary subnet is specified. N/A 113

130 6. (Optional.) Set the address lease duration. expired { allow-hint { day day [ hour hour [ minute minute [ second second ] ] ] unlimited } [ allow-hint ] } The default setting is 1 day. 7. (Optional.) Exclude the specified IP addresses from dynamic allocation. forbidden-ip ip-address&<1-8> By default, all the IP addresses in the DHCP address pool can be dynamically allocated. To exclude multiple address ranges from the address pool, repeat this step. 8. Return to system view. quit N/A 9. (Optional.) Exclude the specified IP addresses from dynamic allocation globally. dhcp server forbidden-ip start-ip-address [ end-ip-address ] Except for the IP address of the DHCP server interface, IP addresses in all address pools are assignable by default. To exclude multiple address ranges globally, repeat this step. Configuring a static binding in a DHCP address pool Some DHCP clients, such as a WWW server, need fixed IP addresses. To provide a fixed IP address for a client, you can statically bind the MAC address or ID of the client to an IP address in a DHCP address pool. When the client requests an IP address, the DHCP server assigns the IP address in the static binding to the client. Follow these guidelines when you configure a static binding: One IP address can be bound to only one client MAC or client ID. You cannot modify bindings that have been created. To change the binding for a DHCP client, you must delete the existing binding first. The IP address of a static binding cannot be the address of the DHCP server interface. Otherwise, an IP address conflict occurs and the bound client cannot obtain an IP address correctly. Multiple interfaces on the same device might all use DHCP to request a static IP address. In this case, use client IDs rather than the device's MAC address to identify the interfaces. Otherwise, IP address allocation will fail. To configure a static binding: 2. Enter DHCP address pool view. dhcp server ip-pool pool-name By default, no DHCP address pool exists. 3. Configure a static binding. static-bind ip-address ip-address [ mask-length mask mask ] { client-identifier client-identifier hardware-address hardware-address [ ethernet token-ring ] } By default, no static binding is configured. To add more static bindings, repeat this step. 114

131 4. (Optional.) Set the lease duration for the IP address. expired { allow-hint { day day [ hour hour [ minute minute [ second second ] ] ] unlimited } [ allow-hint ] } The default setting is 1 day. Specifying gateways for DHCP clients DHCP clients send packets destined for other networks to a gateway. The DHCP server can assign the gateway address to the DHCP clients. You can specify gateway addresses in each address pool on the DHCP server. A maximum of 64 gateways can be specified in DHCP address pool view or secondary subnet view. The DHCP server assigns gateway addresses to clients on a secondary subnet in the following ways: If gateways are specified in both address pool view and secondary subnet view, DHCP assigns those specified in the secondary subnet view. If gateways are specified in address pool view but not in secondary subnet view, DHCP assigns those specified in address pool view. To configure gateways in the DHCP address pool: 2. Enter DHCP address pool view. dhcp server ip-pool pool-name By default, no DHCP address pool exists. 3. Specify gateways. gateway-list ip-address&<1-64> 4. (Optional.) Enter secondary subnet view network network-address [ mask-length mask mask ] secondary 5. (Optional.) Specify gateways. gateway-list ip-address&<1-64> By default, no gateway is specified. N/A By default, no gateway is specified. Specifying a domain name suffix for DHCP clients You can specify a domain name suffix in a DHCP address pool on the DHCP server. With this suffix assigned, the client only needs to input part of a domain name, and the system adds the domain name suffix for name resolution. For more information about DNS, see Layer 3 IP Services Configuration Guide. To configure a domain name suffix in the DHCP address pool: 2. Enter DHCP address pool view. dhcp server ip-pool pool-name 3. Specify a domain name suffix. domain-name domain-name By default, no DHCP address pool exists. By default, no domain name is specified. 115

132 Specifying DNS servers for DHCP clients To access hosts on the Internet through domain names, a DHCP client must contact a DNS server to resolve names. You can specify up to eight DNS servers in a DHCP address pool. To specify DNS servers in a DHCP address pool: 2. Enter DHCP address pool view. dhcp server ip-pool pool-name 3. Specify DNS servers. dns-list ip-address&<1-8> By default, no DHCP address pool exists. By default, no DNS server is specified. Specifying WINS servers and NetBIOS node type for DHCP clients A Microsoft DHCP client using NetBIOS protocol must contact a WINS server for name resolution. You can specify up to eight WINS servers for such clients in a DHCP address pool. In addition, you must specify one of the following NetBIOS node types to approach name resolution: b (broadcast)-node A b-node client sends the destination name in a broadcast message. The destination returns its IP address to the client after receiving the message. p (peer-to-peer)-node A p-node client sends the destination name in a unicast message to the WINS server. The WINS server returns the destination IP address. m (mixed)-node An m-node client broadcasts the destination name. If it receives no response, it unicasts the destination name to the WINS server to get the destination IP address. h (hybrid)-node An h-node client unicasts the destination name to the WINS server. If it receives no response, it broadcasts the destination name to get the destination IP address. To configure WINS servers and NetBIOS node type in a DHCP address pool: 2. Enter DHCP address pool view. dhcp server ip-pool pool-name By default, no DHCP address pool exists. 3. Specify WINS servers. nbns-list ip-address&<1-8> 4. Specify the NetBIOS node type. netbios-type { b-node h-node m-node p-node } This step is optional for b-node. By default, no WINS server is specified. By default, no NetBIOS node type is specified. Specifying BIMS server for DHCP clients Perform this task to provide the BIMS server IP address, port number, and shared key for the clients. The DHCP clients contact the BIMS server to get configuration files and perform software upgrade and backup. To configure the BIMS server IP address, port number, and shared key in the DHCP address pool: 116

133 2. Enter DHCP address pool view. 3. Specify the BIMS server IP address, port number, and shared key. dhcp server ip-pool pool-name bims-server ip ip-address [ port port-number ] sharekey { cipher simple } string By default, no DHCP address pool exists. By default, no BIMS server information is specified. Specifying the configuration file for DHCP client auto-configuration Auto-configuration enables a device to obtain a set of configuration settings automatically from servers when the device starts up without a next-startup configuration file. It requires the cooperation of the DHCP server, HTTP server, DNS server, and TFTP server. For more information about auto-configuration, see Fundamentals Configuration Guide. Follow these guidelines to specify the parameters on the DHCP server for configuration file acquisition: If the configuration file is on a TFTP server, specify the IP address or name of the TFTP server, and the configuration file name. If the configuration file is on an HTTP server, specify the configuration file URL. The DHCP client uses the obtained parameters to contact the TFTP server or the HTTP server to get the configuration file. Specifying the configuration file name in a DHCP address pool 2. Enter DHCP address pool view. dhcp server ip-pool pool-name 3. Specify the IP address or the name of a TFTP server. 4. Specify the configuration file name. Specify the IP address of the TFTP server: tftp-server ip-address ip-address Specify the name of the TFTP server: tftp-server domain-name domain-name bootfile-name bootfile-name By default, no DHCP address pool exists. You can specify both the IP address and name of the TFTP server. By default, no TFTP server is specified. By default, no configuration file name is specified. Specifying the configuration file URL in a DHCP address pool 2. Enter DHCP address pool view. 3. Specify the URL of the configuration file. dhcp server ip-pool pool-name bootfile-name url By default, no DHCP address pool exists. By default, no configuration file URL is specified. 117

134 Specifying a server for DHCP clients Some DHCP clients need to obtain configuration information from a server, such as a TFTP server. You can specify the IP address of that server. The DHCP server sends the server's IP address to DHCP clients along with other configuration information. To specify the IP address of a server: 2. Enter DHCP address pool view. 3. Specify the IP address of a server. dhcp server ip-pool pool-name next-server ip-address By default, no DHCP address pool exists. By default, no server is specified. Configuring Option 184 parameters for DHCP clients To assign calling parameters to DHCP clients with voice service, you must configure Option 184 on the DHCP server. For more information about Option 184, see "Option 184." To configure option 184 parameters in a DHCP address pool: 2. Enter DHCP address pool view. dhcp server ip-pool pool-name By default, no DHCP address pool exists. 3. Specify the IP address of the primary network calling processor. 4. (Optional.) Specify the IP address for the backup server. 5. (Optional.) Configure the voice VLAN. 6. (Optional.) Specify the failover IP address and dialer string. voice-config ncp-ip ip-address voice-config as-ip ip-address voice-config voice-vlan vlan-id { disable enable } voice-config fail-over ip-address dialer-string By default, no primary network calling processor is specified. After you configure this command, the other Option 184 parameters take effect. By default, no backup network calling processor is specified. By default, no voice VLAN is configured. By default, no failover IP address or dialer string is specified. Customizing DHCP options IMPORTANT: Use caution when customizing DHCP options because the configuration might affect DHCP operation. DHCP option customization applications You can customize options for the following purposes: 118

135 Add newly released options. Add options for which the vendor defines the contents, for example, Option 43. Add options for which the CLI does not provide a dedicated configuration command. For example, you can use the option 4 ip-address command to define the time server address for DHCP clients. Add all option values if the actual requirement exceeds the limit for a dedicated option configuration command. For example, the dns-list command can specify up to eight DNS servers. To specify more than eight DNS servers, you must use the option 6 command to define all DNS servers. Common DHCP options Table 7 lists common DHCP options and their parameters. Table 7 Common DHCP options Option Option name Corresponding command 3 Router Option gateway-list ip-address 6 Domain Name Server Option dns-list ip-address 15 Domain Name domain-name ascii Recommended option command parameters 44 NetBIOS over TCP/IP Name Server Option nbns-list ip-address 46 NetBIOS over TCP/IP Node Type Option netbios-type hex 66 TFTP server name tftp-server ascii 67 Boot file name bootfile-name ascii 43 Vendor Specific Information N/A hex Customizing a DHCP option in a DHCP address pool 2. Enter DHCP address pool view. 3. Customize a DHCP option. dhcp server ip-pool pool-name option code { ascii ascii-string hex hex-string ip-address ip-address&<1-8> } By default, no DHCP address pool exists. By default, no DHCP option is customized in a DHCP address pool. DHCP options specified in DHCP option groups take precedence over those specified in DHCP address pools. Customizing a DHCP option in a DHCP option group You can customize a DHCP option in a DHCP option group, and specify the option group for a user class in an address pool. A DHCP client in the user class will obtain the option configuration. To customize a DHCP option in a DHCP option group: 119

136 2. Create a DHCP option group and enter DHCP option group view. dhcp option group option-group-number By default, no DHCP option group exists. 3. Customize a DHCP option. 4. Enter DHCP address pool view. 5. Specify the DHCP option group for the DHCP user class. option code { ascii ascii-string hex hex-string ip-address ip-address&<1-8> } dhcp server ip-pool pool-name class class-name option group option-group-number By default, no DHCP option is customized in a DHCP option group. DHCP options specified in DHCP option groups take precedence over those specified in DHCP address pools. By default, no DHCP address pool exists. By default, no DHCP option group is specified for a DHCP user class. Configuring the DHCP user class whitelist The DHCP user class whitelist allows the DHCP server to process requests only from clients on the DHCP user class whitelist. The whitelist does not take effect on clients who request static IP addresses, and the server always processes their requests. To configure the DHCP user class whitelist: 2. Enter DHCP address pool view. 3. Enable the DHCP user class whitelist. 4. Add DHCP user classes to the DHCP user class whitelist. dhcp server ip-pool pool-name verify class valid class class-name&<1-8> By default, no DHCP address pool exists. By default, the DHCP user class whitelist is disabled. By default, no DHCP user class is on the DHCP user class whitelist. Enabling DHCP You must enable DHCP to validate other DHCP configurations. To enable DHCP: 2. Enable DHCP. dhcp enable By default, DHCP is disabled. 120

137 Enabling the DHCP server on an interface Perform this task to enable the DHCP server on an interface. Upon receiving a DHCP request on the interface, the DHCP server assigns the client an IP address and other configuration parameters from a DHCP address pool. To enable the DHCP server on an interface: 2. Enter interface view. interface interface-type interface-number N/A 3. Enable the DHCP server on the interface. dhcp select server By default, the DHCP server on the interface is enabled. Applying a DHCP address pool to a VPN instance If a DHCP address pool is applied to a VPN instance, the DHCP server assigns IP addresses in this address pool to clients in the VPN instance. Addresses in this address pool will not be assigned to clients on the public network. The DHCP server can obtain the VPN instance to which a DHCP client belongs from the following information: The client's VPN information stored in authentication modules, such as IPoE. The VPN information of the DHCP server's interface that receives DHCP packets from the client. If both VPN instances can be obtained, the VPN information from authentication modules takes priority over the VPN information of the receiving interface. An MCE acting as the DHCP server can assign IP addresses not only to clients on public networks, but also to clients on private networks. The IP address ranges of public and private networks or those of private networks on the DHCP server cannot overlap. For more information about MCE, see MPLS Configuration Guide. To apply a DHCP address pool to a VPN instance: 2. Enter DHCP address pool view. 3. Apply the address pool to a VPN instance. dhcp server ip-pool pool-name vpn-instance vpn-instance-name By default, no DHCP address pool exists. By default, the address pool is not applied to any VPN instance. Applying an address pool on an interface Perform this task to apply a DHCP address pool on an interface. Upon receiving a DHCP request from the interface, the DHCP server performs address allocation in the following ways: 121

138 If a static binding is found for the client, the server assigns the static IP address and configuration parameters from the address pool that contains the static binding. If no static binding is found for the client, the server uses the address pool applied to the interface for address and configuration parameter allocation. To apply an address pool on an interface: 2. Enter interface view. 3. Apply an address pool on the interface. interface interface-type interface-number dhcp server apply ip-pool pool-name N/A By default, no address pool is applied on an interface. If the applied address pool does not exist, the DHCP server fails to perform dynamic address allocation. Configuring a DHCP policy for dynamic address assignment In a DHCP policy, each DHCP user class has a bound DHCP address pool. Clients matching different user classes obtain IP addresses and other parameters from different address pools. The DHCP policy must be applied to the interface that acts as the DHCP server. When receiving a DHCP request, the DHCP server compares the packet against the user classes in the order that they are configured. If a matching user class is found and the bound address pool has assignable IP addresses, the server assigns an IP address and other parameters from the address pool. If the address pool does not have assignable IP addresses, the address assignment fails. If no match is found, the server assigns an IP address and other parameters from the default DHCP address pool. If no default address pool is specified or the default address pool does not have assignable IP addresses, the address assignment fails. For successful address assignment, make sure the applied DHCP policy and the bound address pools exist. To configure a DHCP policy for dynamic address assignment: 2. Create a DHCP policy and enter DHCP policy view. 3. Specify a DHCP address pool for a DHCP user class. 4. Specify the default DHCP address pool. dhcp policy policy-name class class-name ip-pool pool-name default ip-pool pool-name By default, no DHCP policy exists. By default, no address pool is specified for a user class. By default, no default address pool is specified. 5. Return to system view. quit N/A 6. Enter interface view. 7. Apply the DHCP policy to the interface. interface interface-type interface-number dhcp apply-policy policy-name N/A By default, no DHCP policy is applied to an interface. 122

139 Allocating different IP addresses to DHCP clients with the same MAC Traditionally, the DHCP server identifies DHCP clients based on their MAC addresses. Each MAC address can be bound to only one IP address. However, DHCP clients that have the same MAC address exist in the network, and each client requires an IP address. You can enable this feature to allocate different IP addresses to such clients. This feature enables the DHCP server to use the following methods to identify the DHCP clients that have the same MAC address: If a DHCP snooping device or a DHCP relay agent exist, you must enable the DHCP snooping device or the DHCP relay agent to support Option 82. The DHCP server identifies a DHCP client by the MAC address of the client and the Option 82 in the DHCP request. If no DHCP snooping device or DHCP relay agent is on the network, the DHCP server identifies a DHCP client by the combination of the following information: The MAC address of the client. The interface name in the DHCP request. The VLAN information of the receiving interface. To allocate different IP addresses to DHCP clients with the same MAC address: 2. Enable allocation of different IP addresses to DHCP clients with the same MAC address. dhcp server multi-ip per-mac enable By default, allocation of different IP addresses to DHCP clients with the same MAC address is disabled. Enabling random IP address allocation By default, the DHCP server tries to allocate the same IP address as the previous allocation to the same user. With this feature enabled, the DHCP server tries to allocate a new IP address to a user every time the user acquires an IP address. This feature is applicable to the scenarios where a user must obtain different IP addresses for each IP address acquisition. To enable random IP address allocation: 2. Enter DHCP address pool view. 3. Enable random IP address allocation. dhcp server ip-pool pool-name allocate-new-ip enable By default, no DHCP address pool exists. By default, random IP address allocation is disabled. Configuring IP address conflict detection Before assigning an IP address, the DHCP server pings that IP address. 123

140 If the server receives a response within the specified period, it selects and pings another IP address. If it receives no response, the server continues to ping the IP address until the maximum number of ping packets are sent. If still no response is received, the server assigns the IP address to the requesting client. The DHCP client uses gratuitous ARP to perform IP address conflict detection. To configure IP address conflict detection: 2. (Optional.) Set the maximum number of ping packets to be sent for conflict detection. 3. (Optional.) Set the ping timeout time. dhcp server ping packets number dhcp server ping timeout milliseconds The default setting is one. The value 0 disables IP address conflict detection. The default setting is 500 ms. The value 0 disables IP address conflict detection. Enabling handling of Option 82 Perform this task to enable the DHCP server to handle Option 82. Upon receiving a DHCP request that contains Option 82, the DHCP server adds Option 82 into the DHCP response. If you disable the DHCP to handle Option 82, it does not add Option 82 into the response message. You must enable handling of Option 82 on both the DHCP server and the DHCP relay agent to ensure correct processing for Option 82. For information about enabling handling of Option 82 on the DHCP relay agent, see "Configuring Option 82." To enable the DHCP server to handle Option 82: 2. Enable the server to handle Option 82. dhcp server relay information enable By default, handling of Option 82 is enabled. Disabling Option 60 encapsulation in DHCP replies If one or more DHCP clients cannot resolve Option 60, disable the DHCP server from encapsulating Option 60 in DHCP replies. If you do not disable the capability, the DHCP server encapsulates Option 60 in a DHCP reply in the following situations: The received DHCP packet contains Option 60. Option 60 is configured for the address pool. To disable the DHCP server from encapsulating Option 60 in DHCP replies: 124

141 2. Disable the DHCP server from encapsulating Option 60 in DHCP replies. dhcp server reply-exclude-option60 By default, the DHCP server can encapsulate Option 60 in DHCP replies. Configuring the DHCP server security features Restrictions and guidelines The DHCP server security features are not applicable if a DHCP relay agent exists in the network. This is because the MAC address of the DHCP relay agent is encapsulated as the source MAC address in the DHCP request received by the DHCP server. In this case, you must configure the DHCP relay agent security features. For more information, see "Configuring the DHCP relay agent security features." If you execute both the dhcp flood-protection enable and dhcp server check mac-address commands on an interface, the dhcp server check mac-address command takes effect. Configuring DHCP flood attack protection About DHCP flood attack protection Procedure The DHCP flood attack protection enables the DHCP server to detect DHCP flood attacks according to the DHCP packet rate threshold on a per-mac basis. When the DHCP server receives a DHCP packet from a client (MAC address), it creates a DHCP flood attack entry in check state. If the number of DHCP packets from the same MAC address reaches the upper limit in the detection duration, the server determines that the client is launching a DHCP flood attack. The DHCP flood attack entry changes to the restrain state, and the DHCP server discards the DHCP packets from that client. When the aging time of the entry is reached, the DHCP server deletes the entry. If a DHCP packet from the MAC address arrives later, the DHCP server will create a flood attack entry and count the number of incoming DHCP packets for that client again. To configure DHCP flood attack protection: 2. (Optional) Set the DHCP packet rate threshold for DHCP flood attack detection. 3. (Optional) Set the DHCP flood attack entry aging time. 4. Enter interface view. 5. Enable DHCP flood attack protection. dhcp flood-protection threshold packet-number milliseconds dhcp flood-protection aging-time time interface interface-type interface-number dhcp flood-protection enable By default, the device allows a maximum of 6 DHCP packets per 5000 milliseconds from each DHCP client. The default setting is 300 seconds. N/A By default, DHCP flood attack protection is disabled. 125

142 Configuring DHCP starvation attack protection About DHCP starvation attack protection Procedure A DHCP starvation attack occurs when an attacker constantly sends forged DHCP requests using different MAC addresses in the chaddr field to a DHCP server. This exhausts the IP address resources of the DHCP server so legitimate DHCP clients cannot obtain IP addresses. The DHCP server might also fail to work because of exhaustion of system resources. For information about the fields in the DHCP messages, see "DHCP message format." The following methods are available to relieve or prevent such attacks. To relieve a DHCP starvation attack that uses DHCP packets encapsulated with different source MAC addresses, perform the following configuration on an interface: Execute the mac-address max-mac-count command to set the MAC learning limit. For more information about this command, see Layer 2 LAN Switching Command Reference. Disable unknown frame forwarding when the MAC learning limit is reached. To prevent a DHCP starvation attack that uses DHCP requests encapsulated with the same source MAC address, you can enable MAC address check on the DHCP server. The DHCP server compares the chaddr field of a received DHCP request with the source MAC address in the frame header. If they are the same, the DHCP server verifies this request as legal and processes it. If they are not the same, the server discards the DHCP request. To enable MAC address check: 2. Enter interface view. 3. Enable MAC address check. interface interface-type interface-number dhcp server check mac-address N/A By default, MAC address check is disabled. Configuring DHCP server compatibility Perform this task to enable the DHCP server to support DHCP clients that are incompliant with RFC. Configuring the DHCP server to always broadcast responses By default, the DHCP server broadcasts a response only when the broadcast flag in the DHCP request is set to 1. You can configure the DHCP server to ignore the broadcast flag and always broadcast a response. This feature is useful when some clients set the broadcast flag to 0 but do not accept unicast responses. The DHCP server always unicasts a response in the following situations, regardless of whether this feature is configured or not: The DHCP request is from a DHCP client that has an IP address (the ciaddr field is not 0). The DHCP request is forwarded by a DHCP relay agent from a DHCP client (the giaddr field is not 0). To configure the DHCP server to broadcast all responses: 126

143 2. Enable the DHCP server to broadcast all responses. dhcp server always-broadcast By default, the DHCP server reads the broadcast flag to decide whether to broadcast or unicast a response. Enabling the DHCP server to return a DHCP-NAK message upon client notions of incorrect IP addresses About returning a DHCP-NAK message upon client notions of incorrect IP addresses Procedure A DHCP client can send a DHCP-REQUEST message directly or upon receiving a DHCP-OFFER message. Upon receiving the request, the DHCP server will check if the client notion of its IP address is correct. If the requested IP address is different from the allocated one or has no matching lease record, the DHCP server remains silent by default. After the allocated IP address lease for the client expires, the DHCP server will make response to request from the client. This feature enables the DHCP server to return DHCP-NAK messages if the client notions of their IP addresses are incorrect. After receiving the DHCP-NAK message, the DHCP client will request an IP address again. To enable the DHCP server to return a DHCP-NAK message upon client notions of incorrect IP addresses: 2. Enable the DHCP server to return a DHCP-NAK message if the client notions of their IP addresses are incorrect. dhcp server request-ip-address check By default, the DHCP server does not return a DHCP-NAK message if the client notions of their IP addresses are incorrect. Configure the DHCP server to ignore BOOTP requests The lease duration of the IP addresses obtained by the BOOTP clients is unlimited. For some scenarios that do not allow unlimited leases, you can configure the DHCP server to ignore BOOTP requests. To configure the DHCP server to ignore BOOTP requests: 2. Configure the DHCP server to ignore BOOTP requests. dhcp server bootp ignore By default, the DHCP server processes BOOTP requests. 127

144 Configuring the DHCP server to send BOOTP responses in RFC 1048 format Not all BOOTP clients can send requests that are compatible with RFC By default, the DHCP server does not process the Vend field of RFC 1048-incompliant requests but copies the Vend field into responses. This feature enables the DHCP server to fill the Vend field in RFC 1048-compliant format in DHCP responses to RFC 1048-incompliant requests sent by BOOTP clients. This feature is effective for the BOOTP clients that request statically bound addresses. To configure the DHCP server to send BOOTP responses in RFC 1048 format: 2. Enable the DHCP server to send BOOTP responses in RFC 1048 format to the RFC 1048-incompliant BOOTP requests for statically bound addresses. dhcp server bootp reply-rfc-1048 By default, the DHCP server directly copies the Vend field of such requests into the responses. Setting the DSCP value for DHCP packets sent by the DHCP server The DSCP value of a packet specifies the priority level of the packet and affects the transmission priority of the packet. To set the DSCP value for DHCP packets sent by the DHCP server: 2. Set the DSCP value for DHCP packets sent by the DHCP server. dhcp dscp dscp-value By default, the DSCP value in DHCP packets sent by the DHCP server is 56. Configuring DHCP packet rate limit on a DHCP server interface With this feature enabled, an interface discards DHCP packets that exceed the maximum rate. To configure DHCP packet rate limit: 2. Enter interface view. 3. Enable DHCP packet rate limit on an interface and set the limit value. interface interface-type interface-number dhcp rate-limit rate N/A By default, DHCP packet rate limit is disabled on an interface. 128

145 Configuring DHCP binding auto backup The auto backup feature saves bindings to a backup file and allows the DHCP server to download the bindings from the backup file at the server reboot. The bindings include the lease bindings and conflicted IP addresses. They cannot survive a reboot on the DHCP server. The DHCP server does not provide services during the download process. If a connection error occurs during the process and cannot be repaired in a short amount of time, you can terminate the download operation. Manual interruption allows the DHCP server to provide services without waiting for the connection to be repaired. To configure DHCP binding auto backup: 2. Configure the DHCP server to back up the bindings to a file. 3. (Optional.) Manually save the DHCP bindings to the backup file. 4. (Optional.) Set the waiting time after a DHCP binding change for the DHCP server to update the backup file. 5. (Optional.) Terminate the download of DHCP bindings from the backup file. dhcp server database filename { filename url url [ username username [ password { cipher simple } string ] ] } dhcp server database update now dhcp server database update interval interval dhcp server database update stop By default, the DHCP server does not back up the DHCP bindings. With this command executed, the DHCP server backs up its bindings immediately and runs auto backup. N/A The default waiting time is 300 seconds. If no DHCP binding changes, the backup file is not updated. N/A Binding gateways to DHCP server's MAC address This feature enables the DHCP server to assign different gateway IP addresses to DHCP clients. In addition, the DHCP server uses the gateway IP addresses and the server's MAC address to reply to ARP requests from the clients. As shown in Figure 35, the DHCP server is configured on the access device that provides access for clients of different service types, such as broadband, IPTV, and IP telephone. The clients of different types obtain IP addresses on different subnets. For the clients to access the network, the access interface typically has no IP address configured. You must bind the gateways to the DHCP server's MAC address when specifying gateways for the DHCP clients. 129

146 Figure 35 Network diagram... If the address pool is applied to a VPN instance, the VPN instance must exist. To bind the gateways to the DHCP server's MAC address: 2. Enter DHCP address pool view. 3. Bind the gateways to the device's MAC address. dhcp server ip-pool pool-name gateway-list ip-address&<1-64> export-route By default, no DHCP address pool exists. By default, gateways are not bound to any MAC address. Advertising subnets assigned to clients This feature enables the route management module to advertise subnets assigned to DHCP clients. This feature achieves symmetric routing for traffic of the same host. As shown in Figure 36, Router A and Router B act as both the DHCP server and the BRAS device. The BRAS devices send accounting packets to the RADIUS server. To enable the BRAS devices to collect correct accounting information for each RADIUS user, configure the DHCP server to advertise subnets assigned to clients. The upstream and downstream traffic of a RADIUS user will pass through the same BRAS device. Figure 36 Network diagram If the address pool is applied to a VPN instance, the VPN instance must exist. To configure the subnet advertisement feature: 130

147 2. Create a DHCP address pool and enter its view. 3. Advertise subnets assigned to DHCP clients. dhcp server ip-pool pool-name network network-address [ mask-length mask mask ] export-route [ secondary ] By default, no DHCP address pool exists. By default, the subnets assigned to DHCP clients are not advertised. Enabling client offline detection on the DHCP server The client offline detection feature reclaims an assigned IP address and deletes the binding entry when the ARP entry for the IP address ages out. The feature does not function if an ARP entry is manually deleted. To enable client offline detection on the DHCP server: 2. Enter interface view. interface interface-type interface-number N/A 3. Enable client offline detection. dhcp client-detect By default, client offline detection is disabled on the DHCP server. Configuring SNMP notifications for the DHCP server Perform this task to configure the DHCP module to send SNMP notifications to report the following DHCP server events: Exhaustion or recovery of a DHCP address pool. Usage threshold violation in a DHCP address pool. IP address allocation success rate threshold violation. The SNMP notifications are sent to the SNMP module. For the SNMP notifications to be sent correctly, you must also configure SNMP. For more information about SNMP configuration, see Network Management and Monitoring Configuration Guide. For a DHCP address pool usage threshold violation, the DHCP module also sends a log message to the information center. For log messages to be sent correctly, you must also configure the information center. For information about the information center configuration, see Network Management and Monitoring Configuration Guide. To configure SNMP notifications for the DHCP server: 131

148 2. Enable SNMP notifications for the DHCP server. snmp-agent trap enable dhcp server [ address-exhaust allocated-ip ip-in-use ] By default, SNMP notifications are enabled for the DHCP server. 3. (Optional.) Set the IP address allocation success rate threshold. 4. Enter DHCP address pool view. 5. (Optional.) Set the DHCP address pool usage threshold. dhcp server allocated-ip threshold threshold-value dhcp server ip-pool pool-name ip-in-use threshold threshold-value By default, no SNMP notification is sent for an IP address allocation success rate threshold violation. By default, no DHCP address pool exists. The default threshold is 100%. Enabling DHCP logging on the DHCP server The DHCP logging feature enables the DHCP server to generate DHCP logs and send them to the information center. For information about the log destination and output rule configuration in the information center, see Network Management and Monitoring Configuration Guide. As a best practice, disable this feature if the log generation affects the device performance or reduces the address allocation efficiency. For example, this situation might occur when a large number of clients frequently come online or go offline. To enable DHCP logging on the DHCP server: 2. Enable DHCP logging. dhcp log enable By default, DHCP logging is disabled. Display and maintenance commands for DHCP server IMPORTANT: A restart of the DHCP server or execution of the reset dhcp server ip-in-use command deletes all lease information. The DHCP server denies any DHCP request for lease extension, and the client must request an IP address again. Execute display commands in any view and reset commands in user view. Task Display information about IP address conflicts. Display information about DHCP binding auto backup. Display information about lease-expired IP addresses. Command display dhcp server conflict [ ip ip-address ] [ vpn-instance vpn-instance-name ] display dhcp server database display dhcp server expired [ [ ip ip-address ] [ vpn-instance vpn-instance-name ] pool pool-name ] 132

149 Task Display information about assignable IP addresses. Display information about assigned IP addresses. Display DHCP server statistics. Display information about DHCP address pools. Clear information about IP address conflicts. Clear information about lease-expired IP addresses. Clear information about assigned IP addresses. Clear DHCP server statistics. Command display dhcp server free-ip [ pool pool-name vpn-instance vpn-instance-name ] display dhcp server ip-in-use [ [ ip ip-address ] [ vpn-instance vpn-instance-name ] pool pool-name ] display dhcp server statistics [ pool pool-name vpn-instance vpn-instance-name ] display dhcp server pool [ pool-name vpn-instance vpn-instance-name ] reset dhcp server conflict [ ip ip-address ] [ vpn-instance vpn-instance-name ] reset dhcp server expired [ [ ip ip-address ] [ vpn-instance vpn-instance-name ] pool pool-name ] reset dhcp server ip-in-use [ [ ip ip-address ] [ vpn-instance vpn-instance-name ] pool pool-name ] reset dhcp server statistics [ vpn-instance vpn-instance-name ] DHCP server configuration examples Example: Configuring static IP address assignment Network configuration As shown in Figure 37, Router A (DHCP server) assigns a static IP address, a DNS server address, and a gateway address to Router B (DHCP client) and Router C (BOOTP client). The client ID of the interface GigabitEthernet 1/0/1 on Router B is e e d e The MAC address of the interface GigabitEthernet 1/0/1 on Router C is 000f-e200-01c0. Figure 37 Network diagram Procedure 1. Specify an IP address for GigabitEthernet 1/0/1 on Router A. <RouterA> system-view [RouterA] interface gigabitethernet 1/0/1 133

150 [RouterA-GigabitEthernet1/0/1] ip address [RouterA-GigabitEthernet1/0/1] quit 2. Configure the DHCP server: # Enable DHCP. [RouterA] dhcp enable # Enable the DHCP server on GigabitEthernet 1/0/1. [RouterA] interface gigabitethernet 1/0/1 [RouterA-GigabitEthernet1/0/1] dhcp select server [RouterA-GigabitEthernet1/0/1] quit # Create DHCP address pool 0. [RouterA] dhcp server ip-pool 0 # Configure a static binding for Router B. [RouterA-dhcp-pool-0] static-bind ip-address client-identifier e e d e-6574 # Configure a static binding for Router C. [RouterA-dhcp-pool-0] static-bind ip-address hardware-address 000f-e200-01c0 # Specify the DNS server address and the gateway address. [RouterA-dhcp-pool-0] dns-list [RouterA-dhcp-pool-0] gateway-list [RouterA-dhcp-pool-0] quit [RouterA] Verifying the configuration # Verify that Router B can obtain IP address and all other network parameters from Router A. (Details not shown.) # Verify that Router C can obtain IP address and all other network parameters from Router A. (Details not shown.) # On the DHCP server, display the IP addresses assigned to the clients. [RouterA] display dhcp server ip-in-use IP address Client identifier/ Lease expiration Type Hardware address e Jan 21 14:27: Static(C) e d e f-e200-01c0 Unlimited Static(C) Example: Configuring dynamic IP address assignment Network configuration As shown in Figure 38, the DHCP server (Router A) assigns IP addresses to clients on subnet /24, which is subnetted into /25 and /25. Configure DHCP server on Router A to implement the following assignment scheme. 134

151 Table 8 Assignment scheme DHCP clients IP address Lease Other configuration parameters Clients connected to GigabitEthernet 1/0/1 Clients connected to GigabitEthernet 1/0/2 Figure 38 Network diagram IP addresses on subnet /25 IP addresses on subnet /25 10 days and 12 hours Five days Gateway: /25 DNS server: /25 Domain name: aabbcc.com WINS server: /25 Gateway: /25 DNS server: /25 Domain name: aabbcc.com Procedure 1. Specify IP addresses for interfaces. (Details not shown.) 2. Configure the DHCP server: # Enable DHCP. <RouterA> system-view [RouterA] dhcp enable # Enable the DHCP server on GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2. [RouterA] interface gigabitethernet 1/0/1 [RouterA-GigabitEthernet1/0/1] dhcp select server [RouterA-GigabitEthernet1/0/1] quit [RouterA] interface gigabitethernet 1/0/2 [RouterA-GigabitEthernet1/0/2] dhcp select server [RouterA-GigabitEthernet1/0/2] quit # Exclude the IP addresses of the DNS server, WINS server, and gateways from dynamic allocation. [RouterA] dhcp server forbidden-ip [RouterA] dhcp server forbidden-ip [RouterA] dhcp server forbidden-ip [RouterA] dhcp server forbidden-ip # Configure DHCP address pool 1 to assign IP addresses and other configuration parameters to clients on subnet /25. [RouterA] dhcp server ip-pool 1 [RouterA-dhcp-pool-1] network mask [RouterA-dhcp-pool-1] expired day 10 hour

152 [RouterA-dhcp-pool-1] domain-name aabbcc.com [RouterA-dhcp-pool-1] dns-list [RouterA-dhcp-pool-1] gateway-list [RouterA-dhcp-pool-1] nbns-list [RouterA-dhcp-pool-1] quit # Configure DHCP address pool 2 to assign IP addresses and other configuration parameters to clients on subnet /25. [RouterA] dhcp server ip-pool 2 [RouterA-dhcp-pool-2] network mask [RouterA-dhcp-pool-2] expired day 5 [RouterA-dhcp-pool-2] domain-name aabbcc.com [RouterA-dhcp-pool-2] dns-list [RouterA-dhcp-pool-2] gateway-list [RouterA-dhcp-pool-2] quit Verifying the configuration # Verify that clients on subnets /25 and /25 can obtain correct IP addresses and all other network parameters from Router A. (Details not shown.) # On the DHCP server, display the IP addresses assigned to the clients. [RouterA] display dhcp server ip-in-use IP address Client identifier/ Lease expiration Type Hardware address e Jan 14 22:25: Auto(C) e d f fe e02- Jan 14 22:25: Auto(C) b e-712f-5e e Jan 9 10:45: Auto(C) 662e d e fe Jan 9 10:45: Auto(C) e Jan 9 10:45: Auto(C) 7e a d Jan 9 10:45: Auto(C) e Example: Configuring DHCP user class Network configuration As shown in Figure 39, the DHCP relay agent (Router A) forwards DHCP packets between DHCP clients and the DHCP server (Router B). Enable Router A to handle Option 82 so that it can add Option 82 in DHCP requests and then forward them to the DHCP server. Configure the address allocation scheme as follows: 136

153 Assign IP addresses To clients to The DHCP request contains Option to The hardware address in the request is six bytes long and begins with aabb-aabb-aab. Router B assigns the DNS server address /24 and the gateway address /24 to clients on subnet /24. Figure 39 Network diagram Procedure 1. Specify IP addresses for the interfaces on the DHCP server. (Details not shown.) 2. Configure DHCP: # Enable DHCP and configure the DHCP server to handle Option 82. <RouterB> system-view [RouterB] dhcp enable [RouterB] dhcp server relay information enable # Enable the DHCP server on the interface GigabitEthernet1/0/1. [RouterB] interface gigabitethernet 1/0/1 [RouterB-GigabitEthernet1/0/1] dhcp select server [RouterB-GigabitEthernet1/0/1] quit # Create DHCP user class tt and configure a match rule to match DHCP requests that contain Option 82. [RouterB] dhcp class tt [RouterB-dhcp-class-tt] if-match rule 1 option 82 [RouterB-dhcp-class-tt] quit # Create DHCP user class ss and configure a match rule to match DHCP requests in which the hardware address is six bytes long and begins with aabb-aabb-aab. [RouterB] dhcp class ss [RouterB-dhcp-class-ss] if-match rule 1 hardware-address aabb-aabb-aab0 mask ffff-ffff-fff0 [RouterB-dhcp-class-ss] quit # Create DHCP address pool aa. [RouterB] dhcp server ip-pool aa # Specify the subnet for dynamic allocation. [RouterB-dhcp-pool-aa] network mask

154 # Specify the address range for dynamic allocation. [RouterB-dhcp-pool-aa] address range # Specify the address range for user class tt. [RouterB-dhcp-pool-aa] class tt range # Specify the address range for user class ss. [RouterB-dhcp-pool-aa] class ss range # Specify the gateway address and the DNS server address. [RouterB-dhcp-pool-aa] gateway-list [RouterB-dhcp-pool-aa] dns-list [RouterB-dhcp-pool-aa] quit Verifying the configuration # Verify that clients matching the DHCP user classes can obtain IP addresses in the specified ranges and all other configuration parameters from the DHCP server. (Details not shown.) # On the DHCP server, display the IP addresses assigned to the clients. [RouterB] display dhcp server ip-in-use IP address Client identifier/ Lease expiration Type Hardware address e Jan 14 22:25: Auto(C) e d f aabb-aabb-aab1 Jan 14 22:25: Auto(C) Example: Configuring DHCP user class whitelist Network configuration As shown in Figure 40, configure the DHCP user class whitelist to allow the DHCP server to assign IP addresses to clients whose hardware addresses are six bytes long and begin with aabb-aabb. Figure 40 Network diagram Procedure 1. Specify IP addresses for the interfaces on the DHCP server. (Details not shown.) 2. Configure DHCP: # Enable DHCP. <RouterB> system-view [RouterB] dhcp enable # Enable the DHCP server on GigabitEthernet 1/0/1. [RouterB] interface gigabitethernet 1/0/1 [RouterB-GigabitEthernet1/0/1] dhcp select server [RouterB-GigabitEthernet1/0/1] quit # Create DHCP user class ss and configure a match rule to match DHCP requests in which the hardware address is six bytes long and begins with aabb-aabb. [RouterB] dhcp class ss 138

155 [RouterB-dhcp-class-ss] if-match rule 1 hardware-address aabb-aabb-0000 mask ffff-ffff-0000 [RouterB-dhcp-class-ss] quit # Create DHCP address pool aa. [RouterB] dhcp server ip-pool aa # Specify the subnet for dynamic allocation. [RouterB-dhcp-pool-aa] network mask # Enable the DHCP user class whitelist. [RouterB-dhcp-pool-aa] verify class # Add DHCP user class ss to the DHCP user class whitelist. [RouterB-dhcp-pool-aa] valid class ss [RouterB-dhcp-pool-aa] quit Verifying the configuration # Verify that clients matching the DHCP user class can obtain IP addresses on subnet /24 from the DHCP server. (Details not shown.) # On the DHCP server, display the IP addresses assigned to the clients. [RouterB] display dhcp server ip-in-use IP address Client identifier/ Lease expiration Type Hardware address aabb-aabb-ab01 Jan 14 22:25: Auto(C) Example: Configuring primary and secondary subnets Network configuration As shown in Figure 41, the DHCP server (Router A) assigns IP addresses to DHCP clients in the LAN. Configure two subnets in the address pool on the DHCP server: /24 as the primary subnet and /24 as the secondary subnet. The DHCP server selects an IP address from the secondary subnet when the primary subnet has no assignable addresses. Router A assigns the following parameters: The default gateway /24 to clients on subnet /24. The default gateway /24 to clients on subnet /24. Figure 41 Network diagram Router A DHCP server GE1/0/ / /24 sub... DHCP client DHCP client DHCP client Gateway 139

156 Procedure # Enable DHCP. <RouterA> system-view [RouterA] dhcp enable # Configure the primary and secondary IP addresses of GigabitEthernet1/0/1, and enable the DHCP server on GigabitEthernet 1/0/1. [RouterA] interface gigabitethernet 1/0/1 [RouterA-GigabitEthernet1/0/1] ip address [RouterA-GigabitEthernet1/0/1] ip address sub [RouterA-GigabitEthernet1/0/1] dhcp select server [RouterA-GigabitEthernet1/0/1] quit # Create DHCP address pool aa. [RouterA] dhcp server ip-pool aa # Specify the primary subnet and the gateway address for dynamic allocation. [RouterA-dhcp-pool-aa] network mask [RouterA-dhcp-pool-aa] gateway-list # Specify the secondary subnet and the gateway address for dynamic allocation. [RouterA-dhcp-pool-aa] network mask secondary [RouterA-dhcp-pool-aa-secondary] gateway-list [RouterA-dhcp-pool-aa-secondary] quit [RouterA-dhcp-pool-aa] quit Verifying the configuration # Verify that the DHCP server assigns clients IP addresses and gateway address from the secondary subnet when no assignable address is available from the primary subnet. (Details not shown.) # On the DHCP server, display IP addresses assigned to the clients. The following is part of the command output. [RouterA] display dhcp server ip-in-use IP address Client identifier/ Lease expiration Type Hardware address e Jan 14 22:25: Auto(C) e d f e Jan 14 22:25: Auto(C) 662e d e Example: Customizing DHCP option Network configuration As shown in Figure 42, DHCP clients obtain IP addresses and PXE server addresses from the DHCP server (Router A). The subnet for address allocation is /24. Configure the address allocation scheme as follows: Assign PXE addresses and To clients The hardware address in the request is six bytes long and begins with aabb-aabb. 140

157 Assign PXE addresses To clients and Other clients. The DHCP server assigns PXE server addresses to DHCP clients through Option 43, a custom option. The formats of Option 43 and PXE server address sub-option are shown in Figure 32 and Figure 34. For example, the value of Option 43 configured in the DHCP address pool is 80 0B The number 80 is the value of the sub-option type. The number 0B is the value of the sub-option length. The numbers are the value of the PXE server type. The number 02 indicates the number of servers. The numbers indicate that the PXE server addresses are and Figure 42 Network diagram Procedure 1. Specify an IP address for GigabitEthernet 1/0/1. (Details not shown.) 2. Configure the DHCP server: # Enable DHCP. <RouterA> system-view [RouterA] dhcp enable # Create DHCP user class ss and configure a match rule to match DHCP requests in which the hardware address is six bytes long and begins with aabb-aabb. [RouterA] dhcp class ss [RouterA-dhcp-class-ss] if-match rule 1 hardware-address aabb-aabb-0000 mask ffff-ffff-0000 [RouterA-dhcp-class-ss] quit # Create DHCP option group 1 and customize Option 43. [RouterA] dhcp option-group 1 [RouterA-dhcp-option-group-1] option 43 hex 800B # Enable the DHCP server on GigabitEthernet 1/0/1. [RouterA] interface gigabitethernet 1/0/1 [RouterA-GigabitEthernet1/0/1] dhcp select server [RouterA-GigabitEthernet1/0/1] quit # Create DHCP address pool 0. [RouterA] dhcp server ip-pool 0 # Specify the subnet for dynamic address allocation. [RouterA-dhcp-pool-0] network mask # Customize Option 43. [RouterA-dhcp-pool-0] option 43 hex 800B # Associate DHCP user class ss with option group 1. [RouterA-dhcp-pool-0] class ss option-group 1 141

158 [RouterA-dhcp-pool-0] quit Verifying the configuration # Verify that Router B can obtain an IP address on subnet /24 and the corresponding PXE server addresses from Router A. (Details not shown.) # On the DHCP server, display the IP addresses assigned to the clients. [RouterA] display dhcp server ip-in-use IP address Client identifier/ Lease expiration Type Hardware address aabb-aabb-ab01 Jan 14 22:25: Auto(C) Example: Configuring DHCP server (WLAN application) Network configuration As shown in Figure 43, the DHCP server (Device) assigns an IP address, the AC address, a gateway address, and a DNS server address to the AP. Configure the DHCP server as follows: Create an address pool, specify the subnet /24, and configure the address lease duration as ten days. Specify the gateway address and the DNS server address as and Configure Option 43. Specify the AC address as The formats of Option 43 and the PXE server address sub-option are shown in Figure 32 and Figure 34. The value of Option 43 configured on the DHCP server in this example is A The number 80 is the value of the sub-option type. The number 07 is the value of the sub-option length. The numbers are the value of the PXE server type. The number 01 indicates the number of servers. The numbers 0A indicate that the IP address of the AC is To avoid address conflicts, exclude the IP addresses and of the gateway and the AC from dynamic allocation. Figure 43 Network diagram 142

159 Procedure 1. Specify an IP address for GigabitEthernet 1/0/1 on the device. <Device> system-view [Device] interface gigabitethernet 1/0/1 [Device-GigabitEthernet1/0/1] ip address [Device-GigabitEthernet1/0/1] quit 2. Configure the DHCP server: # Enable DHCP. [Device] dhcp enable # Enable the DHCP server on GigabitEthernet 1/0/1. [Device] interface gigabitethernet 1/0/1 [Device-GigabitEthernet1/0/1] ip address dhcp select server [Device-GigabitEthernet1/0/1] quit # Exclude the gateway address and the AC address from dynamic allocation. [Device] dhcp server forbidden-ip [Device] dhcp server forbidden-ip # Configure DHCP address pool 0 for dynamic allocation. [Device] dhcp server ip-pool 0 # Specify the assignable subnet as /24 and the address lease duration as ten days. [Device-dhcp-pool-0] network mask [Device-dhcp-pool-0] expired day 10 # Specify the gateway address as and the DNS server address as [Device-dhcp-pool-0] gateway-list [Device-dhcp-pool-0] dns-list # Specify the AC address as [Device-dhcp-pool-0] option 43 hex A Verifying the configuration # Verify that the AP can obtain an IP address and all other network parameters from Device. (Details not shown.) # On the DHCP server, display the IP address assigned to the AP. [Device] display dhcp server ip-in-use Troubleshooting DHCP server configuration Failure to obtain a non-conflicting IP address Symptom A client's IP address obtained from the DHCP server conflicts with an IP address of another host. Solution Another host on the subnet might have the same IP address. To resolve the problem: 143

160 1. Disable the client's network adapter or disconnect the client's network cable. Ping the IP address of the client from another host to check whether there is a host using the same IP address. 2. If a ping response is received, the IP address has been manually configured on a host. Execute the dhcp server forbidden-ip command on the DHCP server to exclude the IP address from dynamic allocation. 3. Enable the network adapter or connect the network cable, release the IP address, and obtain another one on the client. For example, to release the IP address and obtain another one on a Windows XP DHCP client: a. In Windows environment, execute the cmd command to enter the DOS environment. b. Enter ipconfig /release to relinquish the IP address. c. Enter ipconfig /renew to obtain another IP address. 144

161 Configuring the DHCP relay agent About DHCP relay agent The DHCP relay agent enables clients to get IP addresses and configuration parameters from a DHCP server on another subnet. Figure 44 shows a typical application of the DHCP relay agent. Figure 44 DHCP relay agent application DHCP relay agent operation The DHCP server and client interact with each other in the same way regardless of whether the relay agent exists. For the interaction details, see "IP address allocation process." The following only describes steps related to the DHCP relay agent: 1. After receiving a DHCP-DISCOVER or DHCP-REQUEST broadcast message from a DHCP client, the DHCP relay agent processes the message as follows: a. Fills the giaddr field of the message with its IP address. b. Unicasts the message to the designated DHCP server. 2. Based on the giaddr field, the DHCP server returns an IP address and other configuration parameters in a response. 3. The relay agent conveys the response to the client. 145

162 Figure 45 DHCP relay agent operation DHCP relay agent support for Option 82 Option 82 records the location information about the DHCP client. It enables the administrator to perform the following tasks: Locate the DHCP client for security and accounting purposes. Assign IP addresses in a specific range to clients. For more information about Option 82, see "Relay agent option (Option 82)." If the DHCP relay agent supports Option 82, it handles DHCP requests by following the strategies described in Table 9. If a response returned by the DHCP server contains Option 82, the DHCP relay agent removes the Option 82 before forwarding the response to the client. Table 9 Handling strategies of the DHCP relay agent If a DHCP request has Handling strategy Drop The DHCP relay agent Drops the message. Option 82 Keep Forwards the message without changing Option 82. Replace Forwards the message after replacing the original Option 82 with the Option 82 padded according to the configured padding format, padding content, and code type. No Option 82 N/A Forwards the message after adding Option 82 padded according to the configured padding format, padding content, and code type. DHCP relay agent support for MCE An MCE device acting as the DHCP relay agent can forward DHCP packets between a DHCP server and clients on either a public network or a private network. For more information about MCE, see MPLS Configuration Guide. 146

163 DHCP relay agent tasks at a glance Tasks at a glance (Required.) Enabling DHCP (Required.) Enabling the DHCP relay agent on an interface (Required.) Specifying DHCP servers (Optional.) Configuring the DHCP relay agent security features (Optional.) Configuring the DHCP relay agent to release an IP address (Optional.) Configuring Option 82 (Optional.) Setting the DSCP value for DHCP packets sent by the DHCP relay agent (Optional.) Configuring DHCP packet rate limit on a DHCP relay interface (Optional.) Specifying the DHCP relay agent address for the giaddr field (Optional.) Specifying the source IP address for DHCP requests (Optional.) Configuring the DHCP relay agent to always unicast relayed DHCP responses (Optional.) Configuring forwarding DHCP replies based on Option 82 Enabling DHCP You must enable DHCP to validate other DHCP relay agent settings. To enable DHCP: 2. Enable DHCP. dhcp enable By default, DHCP is disabled. Enabling the DHCP relay agent on an interface With the DHCP relay agent enabled, an interface forwards incoming DHCP requests to a DHCP server. An IP address pool that contains the IP address of the DHCP relay interface must be configured on the DHCP server. Otherwise, the DHCP clients connected to the relay agent cannot obtain correct IP addresses. To enable the DHCP relay agent on an interface: 2. Enter interface view. 3. Enable the DHCP relay agent. interface interface-type interface-number dhcp select relay N/A By default, when DHCP is enabled, an interface operates in the DHCP server mode. 147

164 Specifying DHCP servers Specifying DHCP servers on a relay agent To improve availability, you can specify several DHCP servers on the DHCP relay agent. When the interface receives request messages from clients, the relay agent forwards them to all DHCP servers. Follow these guidelines when you specify a DHCP server address on a relay agent: The IP address of any specified DHCP server must not reside on the same subnet as the IP address of the relay interface. Otherwise, the clients might fail to obtain IP addresses. You can specify a maximum of eight DHCP servers. To specify a DHCP server address on a relay agent: 2. Enter interface view. 3. Specify a DHCP server address on the relay agent. interface interface-type interface-number dhcp relay server-address ip-address N/A By default, no DHCP server address is specified on the relay agent. Configuring a DHCP address pool on a DHCP relay agent About DHCP address pool on a DHCP relay agent This feature allows DHCP clients of the same type to obtain IP addresses and other configuration parameters from the DHCP servers specified in the matching DHCP address pool. It applies to scenarios where the DHCP relay agent connects to clients of the same access type but classified into different types by their locations. In this case, the relay interface typically has no IP address configured. You can use the gateway-list command to specify gateway addresses for clients matching the same DHCP address pool and bind the gateway addresses to the device's MAC address. Example network is the IPoE network. Upon receiving a DHCP DISCOVER or REQUEST from a client that matches a DHCP address pool, the relay agent processes the packet as follows: Fills the giaddr field of the packet with a specified gateway address. Forwards the packet to all DHCP servers in the matching DHCP address pool. The DHCP servers select a DHCP address pool according to the gateway address. Restrictions and guidelines If PPPoE users are in the network, follow these restrictions and guidelines when you configure the DHCP address pool: Enable the DHCP relay agent to record DHCP relay entries by using the dhcp relay client-information record command. When a PPPoE user goes offline, the DHCP relay agent can find a matching relay entry and send a DHCP-RELEASE message to the DHCP server. This mechanism ensures the DHCP server is aware of the releasing of the IP address in a timely manner. The remote-server command also configures the device as a DHCP relay agent. You do not need to enable the DHCP relay agent by using the dhcp select relay command. 148

165 Procedure To configure a DHCP address pool on the DHCP relay agent: 2. Create a DHCP address pool and enter its view. 3. Specify gateway addresses for the clients matching the DHCP address pool. 4. Specify DHCP servers for the DHCP address pool. dhcp server ip-pool pool-name gateway-list ip-address&<1-64> [ export-route ] remote-server ip-address&<1-8> By default, no DHCP address pools exist. By default, no gateway address is specified. By default, no DHCP server is specified for the DHCP address pool. You can specify a maximum of eight DHCP servers for one DHCP address pool for high availability. The relay agent forwards DHCP DISCOVER and REQUEST packets to all DHCP servers in the DHCP address pool. Specifying the DHCP server selecting algorithm About DHCP server selecting algorithm The DHCP relay agent supports the polling and master-backup DHCP server selecting algorithms. By default, the DHCP relay agent uses the polling algorithm. It forwards DHCP requests to all DHCP servers. The DHCP clients select the DHCP server from which the first received DHCP reply comes. If the DHCP relay agent uses the master-backup algorithm, it forwards DHCP requests to the master DHCP server first. If the master DHCP server is not available, the relay agent forwards the subsequent DHCP requests to a backup DHCP server. If the backup DHCP server is not available, the relay agent selects the next backup DHCP server, and so on. If no backup DHCP server is available, it repeats the process starting from the master DHCP server. The master DHCP server is determined in one of the following ways: In a common network where multiple DHCP server addresses are specified on the DHCP relay interface, the first specified DHCP server is the master. The other DHCP servers are backup. In a network where DHCP address pools are configured on the DHCP relay agent, the first specified DHCP server in a DHCP address pool is the master. The other DHCP servers in the DHCP address pool are backup. DHCP server selection supports the following functions: DHCP server response timeout time The DHCP relay agent determines that a DHCP server is not available if it does not receive any response from the server within the DHCP server response timeout time. The DHCP server response timeout time is configurable and the default is 30 seconds. DHCP server switchback If the DHCP relay agent selects a backup DHCP server, it does not switch back to the master DHCP server by default. You can configure the DHCP relay agent to switch back to the master DHCP server after a delay. If the master DHCP server is available, the DHCP relay agent forwards DHCP requests to the master DHCP server. If the master DHCP server is not available, the DHCP relay agent still uses the backup DHCP server. 149

166 Specifying the DHCP server selecting algorithm in interface view 2. Enter interface view. interface interface-type interface-number N/A 3. Enable the DHCP relay agent. dhcp select relay By default, an interface operates in the DHCP server mode when DHCP is enabled. 4. Specify a DHCP server address. 5. Specify the DHCP server selecting algorithm. 6. (Optional.) Set the DHCP server response timeout time for DHCP server switchover. 7. (Optional.) Enable the switchback to the master DHCP server and set the delay time. dhcp relay server-address ip-address dhcp relay server-address algorithm { master-backup polling } dhcp relay dhcp-server timeout time dhcp relay master-server switch-delay delay-time By default, no DHCP server address is specified. By default, the polling algorithm is used. The DHCP relay agent forwards DHCP requests to all DHCP servers. By default, the DHCP server response timeout time is 30 seconds. By default, the DHCP relay agent does not switch back to the master DHCP server. Specifying the DHCP server selecting algorithm in DHCP address pool view 2. Enter interface view. interface interface-type interface-number N/A 3. Enable the DHCP relay agent. dhcp select relay By default, an interface operates in the DHCP server mode when DHCP is enabled. 4. Return to system view. quit N/A 5. Create a DHCP address pool and enter its view. 6. Specify gateway addresses for the clients matching the DHCP address pool. 7. Specify DHCP servers for the DHCP address pool. 8. Specify the DHCP server selecting algorithm. 9. (Optional.) Set the DHCP server response timeout time for DHCP server switchover. dhcp server ip-pool pool-name gateway-list ip-address&<1-64> [ export-route ] remote-server ip-address&<1-8> dhcp relay server-address algorithm { master-backup polling } dhcp-server timeout time By default, no DHCP address pool exists. By default, the DHCP address pool does not have any gateway addresses. By default, the DHCP address pool does not have any DHCP server IP addresses. You can specify a maximum of eight DHCP servers for one DHCP address pool for high availability. By default, the polling algorithm is used. The DHCP relay agent forwards DHCP requests to all DHCP servers. By default, the DHCP server response timeout time is 30 seconds. 150

167 10. (Optional.) Enable the switchback to the master DHCP server and set the delay time. master-server switch-delay delay-time By default, the DHCP relay agent does not switch back to the master DHCP server. Configuring the DHCP relay agent security features Rustications and guidelines If you execute both the dhcp flood-protection enable and dhcp server check mac-address commands on an interface, the dhcp server check mac-address command takes priority. Enabling the DHCP relay agent to record relay entries Perform this task to enable the DHCP relay agent to automatically record clients' IP-to-MAC bindings (relay entries) after they obtain IP addresses through DHCP. Some security features use the relay entries to check incoming packets and block packets that do not match any entry. In this way, illegal hosts are not able to access external networks through the relay agent. Examples of the security features are ARP address check, authorized ARP, and IP source guard. The DHCP relay agent does not record IP-to-MAC bindings for DHCP clients running on synchronous/asynchronous serial interfaces. To enable the DHCP relay agent to record relay entries: 2. Enable the relay agent to record relay entries. dhcp relay client-information record By default, the relay agent does not record relay entries. Enabling periodic refresh of dynamic relay entries A DHCP client unicasts a DHCP-RELEASE message to the DHCP server to release its IP address. The DHCP relay agent conveys the message to the DHCP server and does not remove the IP-to-MAC entry of the client. With this feature, the DHCP relay agent uses the following information to periodically send a DHCP-REQUEST message to the DHCP server: The IP address of a relay entry. The MAC address of the DHCP relay interface. The relay agent maintains the relay entries depending on what it receives from the DHCP server: If the server returns a DHCP-ACK message or does not return any message within an interval, the DHCP relay agent removes the relay entry. In addition, upon receiving the DHCP-ACK message, the relay agent sends a DHCP-RELEASE message to release the IP address. If the server returns a DHCP-NAK message, the relay agent keeps the relay entry. To enable periodic refresh of dynamic relay entries: 151

168 2. Enable periodic refresh of dynamic relay entries. 3. Set the refresh interval. dhcp relay client-information refresh enable dhcp relay client-information refresh [ auto interval interval ] By default, periodic refresh of dynamic relay entries is enabled. By default, the refresh interval is auto, which is calculated based on the number of total relay entries. Configuring DHCP flood attack protection About DHCP flood attack protection Procedure The DHCP flood attack protection enables the DHCP relay agent to detect DHCP flood attacks according to the DHCP packet rate threshold on a per-mac basis. When the DHCP relay agent receives a DHCP packet from a client (MAC address), it creates a DHCP flood attack entry in check state. If the number of DHCP packets from the same MAC address reaches the upper limit in the detection duration, the relay agent determines that the client is launching a DHCP flood attack. The DHCP flood attack entry changes to the restrain state, and the DHCP relay agent discards the DHCP packets from that client. When the aging time of the entry is reached, the DHCP relay agent deletes the entry. If a DHCP packet from the MAC address arrives later, the DHCP relay agent will create a flood attack entry and count the number of incoming DHCP packets for that client again. To configure DHCP flood attack protection: 2. (Optional) Set the DHCP packet rate threshold for DHCP flood attack detection. 3. (Optional) Set the DHCP flood attack entry aging time. 4. Enter interface view. 5. Enable DHCP flood attack protection. dhcp flood-protection threshold packet-number milliseconds dhcp flood-protection aging-time time interface interface-type interface-number dhcp flood-protection enable By default, the device allows a maximum of 6 DHCP packets per 5000 milliseconds from each DHCP client. The default setting is 300 seconds. N/A By default, DHCP flood attack protection is disabled. Enabling DHCP starvation attack protection A DHCP starvation attack occurs when an attacker constantly sends forged DHCP requests using different MAC addresses in the chaddr field to a DHCP server. This exhausts the IP address resources of the DHCP server so legitimate DHCP clients cannot obtain IP addresses. The DHCP server might also fail to work because of exhaustion of system resources. The following methods are available to relieve or prevent such attacks. To relieve a DHCP starvation attack that uses DHCP packets encapsulated with different source MAC addresses, you can use one of the following methods: 152

169 Limit the number of ARP entries that a Layer 3 interface can learn. Set the MAC learning limit for a Layer 2 port, and disable unknown frame forwarding when the MAC learning limit is reached. To prevent a DHCP starvation attack that uses DHCP requests encapsulated with the same source MAC address, you can enable MAC address check on the DHCP relay agent. The DHCP relay agent compares the chaddr field of a received DHCP request with the source MAC address in the frame header. If they are the same, the DHCP relay agent forwards the request to the DHCP server. If not, the relay agent discards the request. Enable MAC address check only on the DHCP relay agent directly connected to the DHCP clients. A DHCP relay agent changes the source MAC address of DHCP packets before sending them. A MAC address check entry has an aging time. When the aging time expires, both of the following occur: The entry ages out. The DHCP relay agent rechecks the validity of DHCP requests sent from the MAC address in the entry. To enable MAC address check: 2. Set the aging time for MAC address check entries. 3. Enter the interface view. dhcp relay check mac-address aging-time time interface interface-type interface-number The default aging time is 30 seconds. This command takes effect only after you execute the dhcp relay check mac-address command. N/A 4. Enable MAC address check. dhcp relay check mac-address By default, MAC address check is disabled. Enabling DHCP server proxy on the DHCP relay agent The DHCP server proxy feature isolates DHCP servers from DHCP clients and protects DHCP servers against attacks. Upon receiving a response from the server, the DHCP server proxy modifies the server's IP address as the relay interface's IP address before sending out the response. The DHCP client takes the DHCP relay agent as the DHCP server. To configure DHCP server proxy on the DHCP relay agent: 2. Enter interface view. 3. Enable DHCP relay agent and DHCP server proxy on the interface. interface interface-type interface-number dhcp select relay proxy N/A By default, the interface operates in DHCP server mode. 153

170 Enabling client offline detection on the DHCP relay agent The client offline detection on the DHCP relay agent detects the user online status based on the ARP entry aging. When an ARP entry ages out, the DHCP client offline detection feature deletes the relay entry for the IP address and sends a RELEASE message to the DHCP server. The feature does not function if an ARP entry is manually deleted. To enable client offline detection on the DHCP relay agent: 2. Enable the relay agent to record relay entries. 3. Enter interface view. dhcp relay client-information record interface interface-type interface-number By default, the relay agent does not record relay entries. Without relay entries, client offline detection cannot function correctly. N/A 4. Enable the DHCP relay agent. dhcp select relay 5. Enable client offline detection. dhcp client-detect By default, when DHCP is enabled, an interface operates in the DHCP server mode. By default, client offline detection is disabled on the DHCP relay agent. Configuring the DHCP relay agent to release an IP address Configure the relay agent to release the IP address for a relay entry. The relay agent sends a DHCP-RELEASE message to the server and meanwhile deletes the relay entry. Upon receiving the DHCP-RELEASE message, the DHCP server releases the IP address. To configure the DHCP relay agent to release an IP address: 2. Configure the DHCP relay agent to release an IP address. dhcp relay release ip ip-address [ vpn-instance vpn-instance-name ] This command can release only the IP addresses in the recorded relay entries. Configuring Option 82 To support Option 82, you must perform related configuration on both the DHCP server and relay agent. For DHCP server Option 82 configuration, see "Enabling handling of Option 82." To configure Option 82: 154

171 2. Enter interface view. 3. Enable the relay agent to handle Option 82. interface interface-type interface-number dhcp relay information enable N/A By default, handling of Option 82 is disabled. 4. (Optional.) Configure the strategy for handling DHCP requests that contain Option (Optional.) Configure the padding mode and padding format for the Circuit ID sub-option. 6. (Optional.) Configure the padding mode and padding format for the Remote ID sub-option. dhcp relay information strategy { drop keep replace } dhcp relay information circuit-id { bas [ sub-interface-vlan ] [ with-vxlan ] string circuit-id { normal verbose [ node-identifier { mac sysname user-defined node-identifier } ] [ sub-interface-vlan ] [ interface ] } [ format { ascii hex } ] } dhcp relay information remote-id { normal [ format { ascii hex } ] string remote-id sysname } By default, the handling strategy is replace. If the handling strategy is replace, configure a padding mode and a padding format for Option 82. If the handling strategy is keep or drop, you do not need to configure a padding mode or padding format for Option 82. By default, the padding mode for Circuit ID sub-option is normal, and the padding format is hex. The device name (sysname) must not include spaces if it is configured as the padding content for sub-option 1. Otherwise, the DHCP relay agent will fail to add or replace Option 82. By default, the padding mode for the Remote ID sub-option is normal, and the padding format is hex. Setting the DSCP value for DHCP packets sent by the DHCP relay agent The DSCP value of a packet specifies the priority level of the packet and affects the transmission priority of the packet. To set the DSCP value for DHCP packets sent by the DHCP relay agent: 2. Set the DSCP value for DHCP packets sent by the DHCP relay agent. dhcp dscp dscp-value By default, the DSCP value in DHCP packets sent by the DHCP relay agent is

172 Configuring DHCP packet rate limit on a DHCP relay interface IMPORTANT: The feature is available only on the CSPEX cards. This feature enables the DHCP relay interface to discard DHCP packets that exceed the maximum rate. To configure DHCP packet rate limit: 2. Enter interface view. 3. Enable DHCP packet rate limit on the interface and set the limit value. interface interface-type interface-number dhcp rate-limit rate N/A By default, DHCP packet rate limit is disabled on an interface. Specifying the DHCP relay agent address for the giaddr field Manually specifying the DHCP relay agent address for the giaddr field This task allows you to specify the IP addresses to be encapsulated to the giaddr field of the DHCP requests. If you do not specify any DHCP relay agent address, the primary IP address of the DHCP relay interface is encapsulated to the giaddr field of DHCP requests. To manually specify the DHCP relay agent address for the giaddr field: 2. Enter interface view. 3. Specify the DHCP relay agent address to be encapsulated to DHCP requests. interface interface-type interface-number dhcp relay gateway ip-address N/A By default, the primary IP address of the DHCP relay interface is encapsulated to DHCP requests. Configuring smart relay to specify the DHCP relay agent address for the giaddr field The DHCP smart relay feature allows the DHCP relay agent to encapsulate secondary IP addresses when the DHCP server does not send back a DHCP-OFFER message. 156

173 The relay agent initially encapsulates its primary IP address to the giaddr field before forwarding a request to the DHCP server. If no DHCP-OFFER is received, the relay agent allows the client to send a maximum of two requests to the DHCP server by using the primary IP address. If no DHCP-OFFER is returned after two retries, the relay agent switches to a secondary IP address. If the DHCP server still does not respond, the next secondary IP address is used. After the secondary IP addresses are all tried and the DHCP server does not respond, the relay agent repeats the process by starting from the primary IP address. Without this feature, the relay agent only encapsulates the primary IP address to the giaddr field of all requests. On a relay agent where DHCP address pools and gateway addresses are configured, the smart relay feature starts the process from the first gateway address. For more information, see "Configuring smart relay to specify the DHCP relay agent address for the giaddr field in a network with DHCP address pools." Configuring smart relay to specify the DHCP relay agent address for the giaddr field in a common network 2. Enter interface view. interface interface-type interface-number N/A 3. Enable the DHCP relay agent. dhcp select relay 4. Assign primary and secondary IP addresses to the DHCP relay agent. ip address ip-address { mask-length mask } [ sub ] By default, an interface operates in the DHCP server mode when DHCP is enabled. By default, the DHCP relay agent does not have any IP addresses. 5. Return to system view. quit N/A 6. Enable the DHCP smart relay feature. dhcp smart-relay enable By default, the DHCP smart relay feature is disabled. Configuring smart relay to specify the DHCP relay agent address for the giaddr field in a network with DHCP address pools 2. Enter interface view. interface interface-type interface-number N/A 3. Enable the DHCP relay agent. dhcp select relay By default, an interface operates in the DHCP server mode when DHCP is enabled. 4. Return to system view. quit N/A 5. Create a DHCP address pool and enter its view. 6. Specify gateway addresses for the clients matching the DHCP address pool. dhcp server ip-pool pool-name gateway-list ip-address&<1-64> [ export-route ] By default, no DHCP address pool exists. By default, the DHCP address pool does not have any gateway addresses. 157

174 7. Specify DHCP servers for the DHCP address pool. remote-server ip-address&<1-8> 8. Return to system view. quit N/A By default, the DHCP address pool does not have any DHCP server IP addresses. You can specify a maximum of eight DHCP servers for one DHCP address pool for high availability. The relay agent forwards DHCP-DISCOVER and DHCP-REQUEST packets to all DHCP servers in the DHCP address pool. 9. Enable the DHCP smart relay feature. dhcp smart-relay enable By default, the DHCP smart relay feature is disabled. Specifying the source IP address for DHCP requests This task is required if multiple relay interfaces share the same IP address or if a relay interface does not have routes to DHCP servers. You can perform this task to specify an IP address or the IP address of another interface, typically the loopback interface, on the DHCP relay agent as the source IP address for DHCP requests. If you specify the ip-address argument, the relay agent changes not only the source IP address but also the giaddr field of a DHCP request. The DHCP server assigns the client an IP address on the same subnet as the specified IP address in the giaddr field. As a result, the client might not be on the same subnet as the DHCP relay interface (the gateway). To avoid this problem, you must configure Option 82 on the relay interface before specifying the ip-address argument. This configuration enables the DHCP relay agent to insert the primary IP address of the relay interface in Option 82. Based on this option, the DHCP server assigns an IP address on the same subnet as the IP address of the relay interface. The DHCP relay agent looks up the MAC address table for the output interface to forward the DHCP reply packets. If you specify gateway, the relay agent uses the IP address in the giaddr field as the source IP address. If the giaddr field is empty, the relay agent follows the default rule to specify the source IP address for DHCP requests. If you specify relay-interface, the relay agent uses the primary IP address of the relay interface as the source IP address. If this interface does not have an IP address, the relay agent follows the default rule to specify the source IP address for DHCP requests. To specify the source IP address for DHCP requests: 2. Enter interface view. interface interface-type interface-number N/A 158

175 3. Specify the source IP address for DHCP requests. dhcp relay source-address { ip-address [ option { 60 [ option-text ] code } ] gateway relay-interface } By default, the DHCP relay agent uses the primary IP address of the interface that connects to the DHCP server as the source IP address for DHCP requests. If this interface does not have an IP address, the DHCP relay agent uses an IP address that shares the same subnet with the DHCP server. You can specify only one source IP address for DHCP requests on an interface. Configuring the DHCP relay agent to always unicast relayed DHCP responses This feature enables the DHCP relay agent to ignore the broadcast flag and always unicast relayed responses. This feature is useful in some LANs, such as a WLAN network, where broadcast communication is not recommended. To configure the DHCP relay agent to always unicast relayed DHCP responses: 2. Enable the DHCP relay agent to always unicast relayed DHCP responses. dhcp relay always-unicast By default, the DHCP relay agent reads the broadcast flag to decide whether to broadcast or unicast a response. Configuring forwarding DHCP replies based on Option 82 Configure this feature if the DHCP relay agent is required to forward DHCP replies to DHCP clients based on Option 82. For example, an IPRAN network has a primary gateway and a secondary gateway. An L3VE interface is configured as the relay interface on each of the gateways. Multiple L2VE subinterfaces are configured to receive packets. One L2VE subinterface corresponds to one PW. Only the primary gateway receives DHCP requests, but both the primary and secondary gateways might receive DHCP replies. The primary gateway can forward DHCP replies based on locally recorded user information, but the secondary gateway cannot. The secondary gateway can only forward DHCP replies to all PWs. To enable the secondary gateway to forward a DHCP reply to only the intended PW, perform the following tasks: Configure the dhcp relay information enable and dhcp relay information circuit-id (with sub-interface-vlan specified) commands on the primary gateway. Then, when the primary gateway receives a DHCP request, it adds Option 82 to the reply and record the VLAN ID of the L2VE subinterface. Configure the dhcp relay information enable, dhcp relay information circuit-id (with sub-interface-vlan specified), and dhcp relay forward reply by-option82 commands on the 159

176 secondary gateway. Then, when the secondary gateway receives a DHCP reply, it resolves Option 82, records the VLAN ID of the L2VE subinterface, and forwards the reply to the PW. To configure forwarding DHCP replies based on Option 82: 2. Enter interface view. 3. Enable the relay agent to handle Option Configure the padding mode and padding format for the Circuit ID sub-option. 5. Configure the DHCP relay agent to forward DHCP replies based on Option 82. interface interface-type interface-number dhcp relay information enable dhcp relay information circuit-id { bas [ sub-interface-vlan ] [ with-vxlan ] string circuit-id { normal verbose [ node-identifier { mac sysname user-defined node-identifier } ] [ interface ] } [ sub-interface-vlan ] [ format { ascii hex } ] } dhcp relay forward reply by-option82 N/A By default, handling of Option 82 is disabled. By default, the padding mode for the Circuit ID sub-option is normal, and the padding format is hex. The device name (set by using the sysname command) must not include spaces if it is configured as the padding content for sub-option 1. Otherwise, the DHCP relay agent will fail to add or replace Option 82. You must set the padding mode to bas, normal, or verbose, and specify the sub-interface-vlan keyword for this command. By default, the DHCP relay agent does not forward DHCP replies based on Option 82. Display and maintenance commands for DHCP relay agent Execute display commands in any view and reset commands in user view. Task Display information about DHCP servers on an interface. Display Option 82 configuration information on the DHCP relay agent. Display relay entries on the DHCP relay agent. Display packet statistics on the DHCP relay agent. Clear relay entries on the DHCP relay agent. Clear packet statistics on the DHCP relay agent. Command display dhcp relay server-address [ interface interface-type interface-number ] display dhcp relay information [ interface interface-type interface-number ] display dhcp relay client-information [ interface interface-type interface-number ip ip-address [ vpn-instance vpn-instance-name ] ] display dhcp relay statistics [ interface interface-type interface-number ] reset dhcp relay client-information [ interface interface-type interface-number ip ip-address [ vpn-instance vpn-instance-name ] ] reset dhcp relay statistics [ interface interface-type interface-number ] 160

177 DHCP relay agent configuration examples Example: Configuring basic DHCP relay agent Network configuration As shown in Figure 46, configure the DHCP relay agent on Router A. The DHCP relay agent enables DHCP clients to obtain IP addresses and other configuration parameters from the DHCP server on another subnet. Because the DHCP relay agent and server are on different subnets, you need to configure static or dynamic routing to make them reachable to each other. DHCP server configuration is also required to guarantee the client-server communication through the DHCP relay agent. For DHCP server configuration information, see "DHCP server configuration examples." Figure 46 Network diagram DHCP client DHCP client GE1/0/ /24 GE1/0/ /24 Router A DHCP relay agent GE1/0/ /24 Router B DHCP server DHCP client DHCP client Procedure # Specify IP addresses for the interfaces. (Details not shown.) # Enable DHCP. <RouterA> system-view [RouterA] dhcp enable # Enable the DHCP relay agent on GigabitEthernet 1/0/1. [RouterA] interface gigabitethernet 1/0/1 [RouterA-GigabitEthernet1/0/1] dhcp select relay # Specify the IP address of the DHCP server on the relay agent. [RouterA-GigabitEthernet1/0/1] dhcp relay server-address Verifying the configuration # Verify that DHCP clients can obtain IP addresses and all other network parameters from the DHCP server through the DHCP relay agent. (Details not shown.) # Display the statistics of DHCP packets forwarded by the DHCP relay agent. [RouterA] display dhcp relay statistics # Display relay entries if you have enabled relay entry recording on the DHCP relay agent. [RouterA] display dhcp relay client-information 161

178 Example: Configuring Option 82 Network configuration As shown in Figure 46, the DHCP relay agent (Router A) replaces Option 82 in DHCP requests before forwarding them to the DHCP server (Router B). The Circuit ID sub-option is company001. The Remote ID sub-option is device001. To use Option 82, you must also enable the DHCP server to handle Option 82. Procedure # Specify IP addresses for the interfaces. (Details not shown.) # Enable DHCP. <RouterA> system-view [RouterA] dhcp enable # Enable the DHCP relay agent on GigabitEthernet 1/0/1. [RouterA] interface gigabitethernet 1/0/1 [RouterA-GigabitEthernet1/0/1] dhcp select relay # Specify the IP address of the DHCP server on the relay agent. [RouterA-GigabitEthernet1/0/1] dhcp relay server-address # Enable the DHCP relay agent to handle Option 82, and perform Option 82 related configuration. [RouterA-GigabitEthernet1/0/1] dhcp relay information enable [RouterA-GigabitEthernet1/0/1] dhcp relay information strategy replace [RouterA-GigabitEthernet1/0/1] dhcp relay information circuit-id string company001 [RouterA-GigabitEthernet1/0/1] dhcp relay information remote-id string device001 Example: Configuring DHCP server selection Network configuration As shown in Figure 47, the DHCP client and the DHCP servers are in different subnets. DHCP server 1 and DHCP server 2 both have a DHCP address pool that contains IP addresses in subnet /24, but neither has DHCP enabled. Configure the DHCP relay agent for the DHCP client to obtain an IP address in subnet /24 and other configuration parameters from a DHCP server. The DHCP relay agent is connected to the DHCP client through GigabitEthernet 1/0/1, to DHCP server 1 through GigabitEthernet 1/0/2, and to DHCP server 2 through GigabitEthernet 1/0/3. 162

179 Figure 47 Network diagram Procedure 1. Assign IP addresses to interfaces on the routers. (Details not shown.) 2. Configure Router B and Router C as DHCP servers. (Details not shown.) 3. Configure the DHCP relay agent on Router A: # Enable DHCP. <RouterA> system-view [RouterA] dhcp enable # Enable the DHCP relay agent on GigabitEthernet 1/0/1. [RouterA] interface gigabitethernet 1/0/1 [RouterA-GigabitEthernet1/0/1] dhcp select relay # Specify the IP addresses of the DHCP servers. [RouterA-GigabitEthernet1/0/1] dhcp relay server-address [RouterA-GigabitEthernet1/0/1] dhcp relay server-address # Specify the DHCP server selecting algorithm as master-backup. [RouterA-GigabitEthernet1/0/1] dhcp relay server-address algorithm master-backup # Configure the DHCP relay agent to switch back to the master DHCP server 3 minutes after it switches to the backup DHCP server. [RouterA-GigabitEthernet1/0/1] dhcp relay master-server switch-delay 3 [RouterA-GigabitEthernet1/0/1] quit Verifying the configuration # Verify that the DHCP client cannot obtain an IP address and that the following log is output in about 30 seconds. DHCPR/3/DHCPR_SERVERCHANGE: -MDC=1; Switched to the server at because the current server did not respond. # Enable DHCP on the DHCP server at (Details not shown.) # Verify that the DHCP client cannot obtain an IP address and that the following log is output in about 3 minutes. DHCPR/3/DHCPR_SWITCHMASTER: -MDC=1; Switched to the master DHCP server at # Verify that the DHCP client obtains an IP address. (Details not shown.) 163

180 Troubleshooting DHCP relay agent configuration Failure of DHCP clients to obtain configuration parameters through the DHCP relay agent Symptom Solution DHCP clients cannot obtain configuration parameters through the DHCP relay agent. Some problems might occur with the DHCP relay agent or server configuration. To locate the problem, enable debugging and execute the display command on the DHCP relay agent to view the debugging information and interface state information. Check that: DHCP is enabled on the DHCP server and relay agent. The DHCP server has an address pool on the same subnet as the DHCP clients. The DHCP server and DHCP relay agent can reach each other. The DHCP server address specified on the DHCP relay interface connected to the DHCP clients is correct. 164

181 Configuring the DHCP client About DHCP client With DHCP client enabled, an interface uses DHCP to obtain configuration parameters from the DHCP server, for example, an IP address. Restrictions and guidelines: DHCP client configuration The DHCP client configuration is supported only on the Layer 3 Ethernet interfaces (or subinterfaces), VLAN interfaces, and Layer 3 aggregate interfaces on CSPEX (except CSPEX-1204) cards. Enabling the DHCP client on an interface Restrictions and guidelines Procedure Follow these restrictions and guidelines when you enable the DHCP client on an interface: An interface can be configured to acquire an IP address in multiple ways. The new configuration overwrites the old. Secondary IP addresses cannot be configured on an interface that is enabled with the DHCP client. If the interface obtains an IP address on the same segment as another interface on the device, the interface does not use the assigned address. Instead, it requests a new IP address from the DHCP server. To enable the DHCP client on an interface: 2. Enter interface view. 3. Configure an interface to use DHCP for IP address acquisition. interface interface-type interface-number ip address dhcp-alloc N/A By default, an interface does not use DHCP for IP address acquisition. Configuring a DHCP client ID for an interface About DHCP client ID A DHCP client ID is added to the DHCP option 61 to uniquely identify a DHCP client. A DHCP server can specify IP addresses for clients based on their DHCP client IDs. DHCP client ID includes an ID type and a type value. Each ID type has a fixed type value. You can specify a DHCP client ID by using one of the following methods: 165

182 Use an ASCII string as the client ID. If an ASCII string is used, the type value is 00. Use a hexadecimal number as the client ID. If a hexadecimal number is used, the type value is the first two characters in the number. Use the MAC address of an interface to generate a client ID. If this method is used, the type value is 01. The type value of a DHCP client ID can be displayed by the display dhcp server ip-in-use or display dhcp client command. Restrictions and guidelines Procedure Make sure the ID for each DHCP client is unique. To configure a DHCP client ID for an interface: 2. Enter interface view. 3. Configure a DHCP client ID for the interface. interface interface-type interface-number dhcp client identifier { ascii ascii-string hex hex-string mac interface-type interface-number } N/A By default, an interface generates the DHCP client ID based on its MAC address. If the interface has no MAC address, it uses the MAC address of the first Ethernet interface to generate its client ID. Enabling duplicated address detection DHCP client detects IP address conflict through ARP packets. An attacker can act as the IP address owner to send an ARP reply. The spoofing attack makes the client unable to use the IP address assigned by the server. As a best practice, disable duplicate address detection when ARP attacks exist on the network. To enable duplicated address detection: 2. Enable duplicate address detection. dhcp client dad enable By default, the duplicate address detection feature is enabled on an interface. Setting the DSCP value for DHCP packets sent by the DHCP client The DSCP value of a packet specifies the priority level of the packet and affects the transmission priority of the packet. To set the DSCP value for DHCP packets sent by the DHCP client: 166

183 2. Set the DSCP value for DHCP packets sent by the DHCP client. dhcp client dscp dscp-value By default, the DSCP value in DHCP packets sent by the DHCP client is 56. Display and maintenance commands for DHCP client Execute display command in any view. Task Display DHCP client information. Command display dhcp client [ verbose ] [ interface interface-type interface-number ] DHCP client configuration examples Example: Configuring DHCP client Network configuration As shown in Figure 49, Router B contacts the DHCP server through GigabitEthernet 1/0/1 to obtain an IP address, a DNS server address, and static route information. The DHCP client's IP address resides on subnet /24. The DNS server address is The next hop of the static route to subnet /24 is The DHCP server uses Option 121 to assign static route information to DHCP clients. Figure 48 shows the Option 121 format. The destination descriptor field contains the following parts: subnet mask length and destination network address, both in hexadecimal notation. In this example, the destination descriptor is (the subnet mask length is 24 and the network address is in dotted decimal notation). The next hop address is 0A ( in dotted decimal notation). Figure 48 Option 121 format Figure 49 Network diagram GE1/0/ /24 Router A DHCP server / /24 GE1/0/1 Router C /24 DNS server Router B DHCP Client 167

184 Procedure 1. Configure Router A: # Specify an IP address for GigabitEthernet 1/0/1. <RouterA> system-view [RouterA] interface gigabitethernet 1/0/1 [RouterA-GigabitEthernet1/0/1] ip address [RouterA-GigabitEthernet1/0/1] quit # Enable DHCP. [RouterA] dhcp enable # Exclude an IP address from dynamic allocation. [RouterA] dhcp server forbidden-ip # Configure DHCP address pool 0. Specify the subnet, lease duration, DNS server address, and a static route to subnet /24. [RouterA] dhcp server ip-pool 0 [RouterA-dhcp-pool-0] network mask [RouterA-dhcp-pool-0] expired day 10 [RouterA-dhcp-pool-0] dns-list [RouterA-dhcp-pool-0] option 121 hex A Configure Router B: # Configure GigabitEthernet 1/0/1 to use DHCP for IP address acquisition. <RouterB> system-view [RouterB] interface gigabitethernet 1/0/1 [RouterB-GigabitEthernet1/0/1] ip address dhcp-alloc [RouterB-GigabitEthernet1/0/1] quit Verifying the configuration # Display the IP address and other network parameters assigned to Router B. [RouterB] display dhcp client verbose GigabitEthernet1/0/1 DHCP client information: Current state: BOUND Allocated IP: Allocated lease: seconds, T1: seconds, T2: seconds Lease from May 21 19:00: to May 31 19:00: DHCP server: Transaction ID: 0xcde72232 Classless static routes: Destination: , Mask: , NextHop: DNS servers: Client ID type: acsii(type value=00) Client ID value: 000c.29d GE1/0/1 Client ID (with type) hex: e e d f30-2f32 T1 will timeout in 3 days 19 hours 48 minutes 43 seconds # Display the route information on Router B. The output shows that a static route to subnet /24 is added to the routing table. [RouterB] display ip routing-table 168

185 Destinations : 11 Routes : 11 Destination/Mask Proto Pre Cost NextHop Interface /24 Direct GE1/0/ /32 Direct InLoop /24 Static GE1/0/ /32 Direct GE1/0/ /8 Direct InLoop /32 Direct InLoop /32 Direct InLoop /32 Direct InLoop /4 Direct NULL /24 Direct NULL /32 Direct InLoop0 169

186 Configuring DHCP snooping About DHCP snooping DHCP snooping is a security feature for DHCP. DHCP snooping works between the DHCP client and server, or between the DHCP client and DHCP relay agent. It guarantees that DHCP clients obtain IP addresses from authorized DHCP servers. Also, it records IP-to-MAC bindings of DHCP clients (called DHCP snooping entries) for security purposes. DHCP snooping defines trusted and untrusted ports to make sure clients obtain IP addresses only from authorized DHCP servers. Trusted A trusted port can forward DHCP messages correctly to make sure the clients get IP addresses from authorized DHCP servers. Untrusted An untrusted port discards received DHCP-ACK and DHCP-OFFER messages to prevent unauthorized servers from assigning IP addresses. DHCP snooping reads DHCP-ACK messages received from trusted ports and DHCP-REQUEST messages to create DHCP snooping entries. A DHCP snooping entry includes the MAC and IP addresses of a client, the port that connects to the DHCP client, and the VLAN. The following features need to use DHCP snooping entries: ARP attack detection Uses DHCP snooping entries to filter ARP packets from unauthorized clients. For more information, see Security Configuration Guide. IP source guard Uses DHCP snooping entries to filter illegal packets on a per-port basis. For more information, see Security Configuration Guide. VLAN mapping Uses DHCP snooping entries to replace service provider VLAN in packets with customer VLAN before sending the packets to clients. For more information, see Layer 2 LAN Switching Configuration Guide. Application of trusted and untrusted ports Configure ports facing the DHCP server as trusted ports, and configure other ports as untrusted ports. As shown in Figure 50, configure the DHCP snooping device's port that is connected to the DHCP server as a trusted port. The trusted port forwards response messages from the DHCP server to the client. The untrusted port connected to the unauthorized DHCP server discards incoming DHCP response messages. 170

187 Figure 50 Trusted and untrusted ports In a cascaded network as shown in Figure 51, configure the DHCP snooping devices' ports facing the DHCP server as trusted ports. To save system resources, you can enable only the untrusted ports directly connected to the DHCP clients to record DHCP snooping entries. Figure 51 Trusted and untrusted ports in a cascaded network DHCP client Host A GE1/0/1 DHCP snooping Switch A GE1/0/2 DHCP server GE1/0/1 Device GE1/0/4 GE1/0/2 GE1/0/1 DHCP client Host B GE1/0/3 GE1/0/3 DHCP snooping Switch C DHCP client Host C GE1/0/1 GE1/0/4 GE1/0/3 GE1/0/2 DHCP snooping Switch B DHCP client Host D Untrusted ports enabled to record snooping entries Untrusted ports disabled from recording snooping entries Trusted ports DHCP snooping support for Option 82 Option 82 records the location information about the DHCP client so the administrator can locate the DHCP client for security and accounting purposes. For more information about Option 82, see "Relay agent option (Option 82)." DHCP snooping uses the same strategies as the DHCP relay agent to handle Option 82 for DHCP request messages, as shown in Table 10. If a response returned by the DHCP server contains Option 82, DHCP snooping removes Option 82 before forwarding the response to the client. If the response contains no Option 82, DHCP snooping forwards it directly. 171

188 Table 10 Handling strategies If a DHCP request has Handling strategy Drop DHCP snooping Drops the message. Option 82 Keep Forwards the message without changing Option 82. Replace Forwards the message after replacing the original Option 82 with the Option 82 padded according to the configured padding format, padding content, and code type. No Option 82 N/A Forwards the message after adding the Option 82 padded according to the configured padding format, padding content, and code type. Restrictions and guidelines: DHCP snooping configuration The DHCP snooping configuration does not take effect on a Layer 2 Ethernet interface that is an aggregation member port. The configuration takes effect when the interface leaves the aggregation group. Specify the ports connected to authorized DHCP servers as trusted ports to make sure that DHCP clients can obtain valid IP addresses. The trusted ports and the ports connected to DHCP clients must be in the same VLAN. You can specify the following interfaces as trusted ports: Layer 2 Ethernet interfaces, Layer 2 aggregate interfaces, Layer 3 Ethernet interfaces, and Layer 3 aggregate interfaces. For more information about aggregate interfaces, see Layer 2 LAN Switching Configuration Guide. DHCP snooping tasks at a glance Tasks at a glance (Required.) Configuring basic DHCP snooping (Optional.) Configuring Option 82 (Optional.) Configuring DHCP snooping entry auto backup (Optional.) Enabling DHCP starvation attack protection (Optional.) Enabling DHCP-REQUEST attack protection (Optional.) Setting the maximum number of DHCP snooping entries (Optional.) Configuring a DHCP packet blocking port (Optional.) Enabling DHCP snooping logging Configuring basic DHCP snooping 172

189 2. Enable DHCP snooping. dhcp snooping enable By default, DHCP snooping is disabled. 3. Enter interface view. 4. Specify the port as a trusted port. interface interface-type interface-number dhcp snooping trust This interface must connect to the DHCP server. By default, all ports are untrusted ports after DHCP snooping is enabled. 5. Return to system view. quit N/A 6. Enter interface view. 7. (Optional.) Enable the recording of DHCP snooping entries. interface interface-type interface-number dhcp snooping binding record This interface must connect to the DHCP client. By default, the recording of DHCP snooping entries is disabled. Configuring Option 82 Restrictions and guidelines Procedure Follow these guidelines when you configure Option 82: The Option 82 configuration on a Layer 2 Ethernet interface that has been added to an aggregation group does not take effect unless the interface leaves the aggregation group. To support Option 82, you must configure Option 82 on both the DHCP server and the DHCP snooping device. For information about configuring Option 82 on the DHCP server, see "Enabling handling of Option 82." If the handling strategy is replace, configure a padding mode and padding format for Option 82. If the handling strategy is keep or drop, you do not need to configure any padding mode or padding format for Option 82. The settings do not take effect even if you configure them. If Option 82 contains the device name, the device name must contain no spaces. Otherwise, DHCP snooping drops the message. You can use the sysname command to specify the device name. For more information about this command, see Fundamentals Command Reference. DHCP snooping uses "outer VLAN tag.inner VLAN tag" to fill the VLAN ID field of sub-option 1 in verbose padding format if either of the following conditions exists: DHCP snooping and QinQ work together. DHCP snooping receives a DHCP packet with two VLAN tags. For example, if the outer VLAN tag is 10 and the inner VLAN tag is 20, the VLAN ID field is 000a The hexadecimal digit a represents the outer VLAN tag 10, and the hexadecimal digit 14 represents the inner VLAN tag 20. The device name (sysname) must not include spaces if it is configured as the padding content for sub-option 1. Otherwise, the DHCP snooping device will fail to add or replace Option 82. To configure DHCP snooping to support Option 82: 2. Enter interface view. interface interface-type interface-number N/A 173

190 3. Enable DHCP snooping to support Option (Optional.) Configure a handling strategy for DHCP requests that contain Option 82. dhcp snooping information enable dhcp snooping information strategy { drop keep replace } By default, DHCP snooping does not support Option 82. By default, the handling strategy is replace. 5. (Optional.) Configure the padding mode and padding format for the Circuit ID sub-option. 6. (Optional.) Configure the padding mode and padding format for the Remote ID sub-option. dhcp snooping information circuit-id { [ vlan vlan-id ] string circuit-id { normal verbose [ node-identifier { mac sysname user-defined node-identifier } ] } [ format { ascii hex } ] } dhcp snooping information remote-id { normal [ format { ascii hex } ] [ vlan vlan-id ] string remote-id sysname } By default, the padding mode is normal and the padding format is hex for the Circuit ID sub-option. By default, the padding mode is normal and the padding format is hex for the Remote ID sub-option. Configuring DHCP snooping entry auto backup About DHCP snooping entry auto backup The auto backup feature saves DHCP snooping entries to a backup file, and allows the DHCP snooping device to download the entries from the backup file at device reboot. The entries on the DHCP snooping device cannot survive a reboot. The auto backup helps the security features provide services if these features (such as IP source guard) must use DHCP snooping entries for user authentication. NOTE: If you disable DHCP snooping with the undo dhcp snooping enable command, the device deletes all DHCP snooping entries, including those stored in the backup file. Procedure To save DHCP snooping entries: 2. Configure the DHCP snooping device to back up DHCP snooping entries to a file. 3. (Optional.) Manually save DHCP snooping entries to the backup file. dhcp snooping binding database filename { filename url url [ username username [ password { cipher simple } string ] ] } dhcp snooping binding database update now By default, the DHCP snooping device does not back up DHCP snooping entries. With this command executed, the DHCP snooping device backs up DHCP snooping entries immediately and runs auto backup. This command automatically creates the file if you specify a non-existent file. N/A 174

191 4. (Optional.) Set the waiting time after a DHCP snooping entry change for the DHCP snooping device to update the backup file. dhcp snooping binding database update interval interval The default waiting time is 300 seconds. When a DHCP snooping entry is learned, updated, or removed, the waiting period starts. The DHCP snooping device updates the backup file when the specified waiting period is reached. All changed entries during the period will be saved to the backup file. If no DHCP snooping entry changes, the backup file is not updated. Enabling DHCP starvation attack protection A DHCP starvation attack occurs when an attacker constantly sends forged DHCP requests that contain identical or different sender MAC addresses in the chaddr field to a DHCP server. This attack exhausts the IP address resources of the DHCP server so legitimate DHCP clients cannot obtain IP addresses. The DHCP server might also fail to work because of exhaustion of system resources. For information about the fields of DHCP packet, see "DHCP message format." You can prevent DHCP starvation attacks in the following ways: If the forged DHCP requests contain different sender MAC addresses, use the mac-address max-mac-count command to set the MAC learning limit on a Layer 2 port. For more information about the command, see Layer 2 LAN Switching Command Reference. If the forged DHCP requests contain the same sender MAC address, perform this task to enable MAC address check for DHCP snooping. This feature compares the chaddr field of a received DHCP request with the source MAC address field in the frame header. If they are the same, the request is considered valid and forwarded to the DHCP server. If not, the request is discarded. To enable MAC address check: 2. Enter interface view. interface interface-type interface-number N/A 3. Enable MAC address check. dhcp snooping check mac-address By default, MAC address check is disabled. Enabling DHCP-REQUEST attack protection About DHCP-REQUEST attack protection DHCP-REQUEST messages include DHCP lease renewal packets, DHCP-DECLINE packets, and DHCP-RELEASE packets. This feature prevents the unauthorized clients that forge the DHCP-REQUEST messages from attacking the DHCP server. Attackers can forge DHCP lease renewal packets to renew leases for legitimate DHCP clients that no longer need the IP addresses. These forged messages disable the victim DHCP server from releasing the IP addresses. 175

192 Procedure Attackers can also forge DHCP-DECLINE or DHCP-RELEASE packets to terminate leases for legitimate DHCP clients that still need the IP addresses. To prevent such attacks, you can enable DHCP-REQUEST check. This feature uses DHCP snooping entries to check incoming DHCP-REQUEST messages. If a matching entry is found for a message, this feature compares the entry with the message information. If they are consistent, the message is considered as valid and forwarded to the DHCP server. If they are different, the message is considered as a forged message and is discarded. If no matching entry is found, the message is considered valid and forwarded to the DHCP server. To enable DHCP-REQUEST check: 2. Enter interface view. 3. Enable DHCP-REQUEST check. interface interface-type interface-number dhcp snooping check request-message N/A By default, DHCP-REQUEST check is disabled. Setting the maximum number of DHCP snooping entries Perform this task to prevent the system resources from being overused. To set the maximum number of DHCP snooping entries: 2. Enter interface view. 3. Set the maximum number of DHCP snooping entries for the interface to learn. interface interface-type interface-number dhcp snooping max-learning-num max-number N/A By default, the number of DHCP snooping entries for an interface to learn is unlimited. Configuring a DHCP packet blocking port Perform this task to configure a port as a DHCP packet blocking port. This blocking port drops all incoming DHCP requests. To configure a DHCP packet blocking port: 2. Enter interface view. interface interface-type interface-number 176 N/A

193 3. Configure the port to block DHCP requests. dhcp snooping deny By default, the port does not block DHCP requests. Enabling DHCP snooping logging The DHCP snooping logging feature enables the DHCP snooping device to generate DHCP snooping logs and send them to the information center. For information about the log destination and output rule configuration in the information center, see Network Management and Monitoring Configuration Guide. As a best practice, disable this feature if the log generation affects the device performance. To enable DHCP snooping logging: 2. Enable DHCP snooping logging. dhcp snooping log enable By default, DHCP snooping logging is disabled. Display and maintenance commands for DHCP snooping Execute display commands in any view, and reset commands in user view. Task Display DHCP snooping entries. Display Option 82 configuration information on the DHCP snooping device. (In standalone mode.) Display DHCP packet statistics on the DHCP snooping device. (In IRF mode.) Display DHCP packet statistics on the DHCP snooping device. Display information about trusted ports. Display information about the file that stores DHCP snooping entries. Clear DHCP snooping entries. (In standalone mode.) Clear DHCP packet statistics on the DHCP snooping device. (In IRF mode.) Clear DHCP packet statistics on the DHCP snooping device. Command display dhcp snooping binding [ ip ip-address [ vlan vlan-id ] ] [ verbose ] display dhcp snooping information { all interface interface-type interface-number } display dhcp snooping packet statistics [ slot slot-number ] display dhcp snooping packet statistics [ chassis chassis-number slot slot-number ] display dhcp snooping trust display dhcp snooping binding database reset dhcp snooping binding { all ip ip-address [ vlan vlan-id ] } reset dhcp snooping packet statistics [ slot slot-number ] reset dhcp snooping packet statistics [ chassis chassis-number slot slot-number ] 177

194 DHCP snooping configuration examples Example: Configuring basic DHCP snooping Network configuration As shown in Figure 52, Switch B is connected to the authorized DHCP server through GigabitEthernet 1/0/1, to the unauthorized DHCP server through GigabitEthernet 1/0/3, and to the DHCP client through GigabitEthernet 1/0/2. Configure only the port connected to the authorized DHCP server to forward the responses from the DHCP server. Enable the DHCP snooping device to record clients' IP-to-MAC bindings by reading DHCP-ACK messages received from the trusted port and the DHCP-REQUEST messages. Figure 52 Network diagram Procedure # Enable DHCP snooping. <SwitchB> system-view [SwitchB] dhcp snooping enable # Configure GigabitEthernet 1/0/1 as a trusted port. [SwitchB] interface gigabitethernet 1/0/1 [SwitchB-GigabitEthernet1/0/1] dhcp snooping trust [SwitchB-GigabitEthernet1/0/1] quit # Enable recording clients' IP-to-MAC bindings on GigabitEthernet 1/0/2. [SwitchB] interface gigabitethernet 1/0/2 [SwitchB-GigabitEthernet1/0/2] dhcp snooping binding record [SwitchB-GigabitEthernet1/0/2] quit Verifying the configuration # Verify that the DHCP client can obtain an IP address and other configuration parameters only from the authorized DHCP server. (Details not shown.) # Display the DHCP snooping entry recorded for the client. [SwitchB] display dhcp snooping binding 178

195 Example: Configuring DHCP snooping support for Option 82 Network configuration As shown in Figure 53, enable DHCP snooping and configure Option 82 on Switch B as follows: Configure the handling strategy for DHCP requests that contain Option 82 as replace. On GigabitEthernet 1/0/2, configure the padding content for the Circuit ID sub-option as company001 and for the Remote ID sub-option as device001. On GigabitEthernet 1/0/3, configure the padding mode for the Circuit ID sub-option as verbose, access node identifier as sysname, and padding format as ascii. Configure the padding content for the Remote ID sub-option as device001. Figure 53 Network diagram Procedure # Enable DHCP snooping. <SwitchB> system-view [SwitchB] dhcp snooping enable # Configure GigabitEthernet 1/0/1 as a trusted port. [SwitchB] interface gigabitethernet 1/0/1 [SwitchB-GigabitEthernet1/0/1] dhcp snooping trust [SwitchB-GigabitEthernet1/0/1] quit # Configure Option 82 on GigabitEthernet 1/0/2. [SwitchB] interface gigabitethernet 1/0/2 [SwitchB-GigabitEthernet1/0/2] dhcp snooping information enable [SwitchB-GigabitEthernet1/0/2] dhcp snooping information strategy replace [SwitchB-GigabitEthernet1/0/2] dhcp snooping information circuit-id string company001 [SwitchB-GigabitEthernet1/0/2] dhcp snooping information remote-id string device001 [SwitchB-GigabitEthernet1/0/2] quit # Configure Option 82 on GigabitEthernet 1/0/3. [SwitchB] interface gigabitethernet 1/0/3 [SwitchB-GigabitEthernet1/0/3] dhcp snooping information enable [SwitchB-GigabitEthernet1/0/3] dhcp snooping information strategy replace [SwitchB-GigabitEthernet1/0/3] dhcp snooping information circuit-id verbose node-identifier sysname format ascii [SwitchB-GigabitEthernet1/0/3] dhcp snooping information remote-id string device

196 Verifying the configuration # Display Option 82 configuration information on GigabitEthernet 1/0/2 and GigabitEthernet 1/0/3 on the DHCP snooping device. [SwitchB] display dhcp snooping information 180

197 Configuring the BOOTP client About BOOTP client BOOTP application An interface that acts as a BOOTP client can use BOOTP to obtain information (such as IP address) from the BOOTP server. To use BOOTP, an administrator must configure a BOOTP parameter file for each BOOTP client on the BOOTP server. The parameter file contains information such as MAC address and IP address of a BOOTP client. When a BOOTP client sends a request to the BOOTP server, the BOOTP server searches for the BOOTP parameter file and returns the corresponding configuration information. BOOTP is usually used in relatively stable environments. In network environments that change frequently, DHCP is more suitable. Because a DHCP server can interact with a BOOTP client, you can use the DHCP server to assign an IP address to the BOOTP client. You do not need to configure a BOOTP server. Obtaining an IP address dynamically A BOOTP client dynamically obtains an IP address from a BOOTP server as follows: 1. The BOOTP client broadcasts a BOOTP request, which contains its own MAC address. 2. Upon receiving the request, the BOOTP server searches the configuration file for the IP address and other information according to the BOOTP client's MAC address. 3. The BOOTP server returns a BOOTP response to the BOOTP client. 4. The BOOTP client obtains the IP address from the received response. A DHCP server can take the place of the BOOTP server in the following dynamic IP address acquisition. Protocols and standards RFC 951, Bootstrap Protocol (BOOTP) RFC 2132, DHCP Options and BOOTP Vendor Extensions RFC 1542, Clarifications and Extensions for the Bootstrap Protocol Configuring an interface to use BOOTP for IP address acquisition 2. Enter interface view. interface interface-type interface-number BOOTP client configuration applies only to Layer 3 Ethernet interfaces (including subinterfaces), Layer 3 aggregate interfaces, and VLAN interfaces. 181

198 3. Configure an interface to use BOOTP for IP address acquisition. ip address bootp-alloc By default, an interface does not use BOOTP for IP address acquisition. Display and maintenance commands for BOOTP client Execute display command in any view. Task Display BOOTP client information. Command display bootp client [ interface interface-type interface-number ] BOOTP client configuration examples Example: Configuring BOOTP client Network configuration Procedure As shown in Figure 38, GigabitEthernet 1/0/1 of Router B connects to the LAN to obtain an IP address from the DHCP server by using BOOTP. To make the BOOTP client obtain an IP address from the DHCP server, perform configuration on the DHCP server. For more information, see "DHCP server configuration examples." The following describes the configuration on Router B, which acts as a client. # Configure GigabitEthernet 1/0/1 to use BOOTP to obtain an IP address. <RouterB> system-view [RouterB] interface gigabitethernet 1/0/1 [RouterB-GigabitEthernet1/0/1] ip address bootp-alloc Verifying the configuration # Display the IP address assigned to the BOOTP client. [RouterB] display bootp client 182

199 DHCPv6 overview DHCPv6 provides a framework to assign IPv6 prefixes, IPv6 addresses, and other configuration parameters to hosts. DHCPv6 address/prefix assignment An address/prefix assignment process involves two or four messages. Rapid assignment involving two messages As shown in Figure 54, rapid assignment operates in the following steps: 1. The DHCPv6 client sends to the DHCPv6 server a Solicit message that contains a Rapid Commit option to prefer rapid assignment. 2. If the DHCPv6 server supports rapid assignment, it responds with a Reply message containing the assigned IPv6 address/prefix and other configuration parameters. If the DHCPv6 server does not support rapid assignment, Assignment involving four messages is performed. Figure 54 Rapid assignment involving two messages Assignment involving four messages As shown in Figure 55, four-message assignment operates using the following steps: 1. The DHCPv6 client sends a Solicit message to request an IPv6 address/prefix and other configuration parameters. 2. The DHCPv6 server responds with an Advertise message that contains the assignable address/prefix and other configuration parameters if either of the following conditions exists: The Solicit message does not contain a Rapid Commit option. The DHCPv6 server does not support rapid assignment even though the Solicit message contains a Rapid Commit option. 3. The DHCPv6 client might receive multiple Advertise messages offered by different DHCPv6 servers. It selects an offer according to the receiving sequence and server priority, and sends a Request message to the selected server for confirmation. 4. The DHCPv6 server sends a Reply message to the client, confirming that the address/prefix and other configuration parameters are assigned to the client. 183

200 Figure 55 Assignment involving four messages Address/prefix lease renewal An IPv6 address/prefix assigned by a DHCPv6 server has a valid lifetime. After the valid lifetime expires, the DHCPv6 client cannot use the IPv6 address/prefix. To use the IPv6 address/prefix, the DHCPv6 client must renew the lease time. Figure 56 Using the Renew message for address/prefix lease renewal As shown in Figure 56, at T1, the DHCPv6 client sends a Renew message to the DHCPv6 server. The recommended value of T1 is half the preferred lifetime. The DHCPv6 server responds with a Reply message, informing the client whether the lease is renewed. Figure 57 Using the Rebind message for address/prefix lease renewal As shown in Figure 57: If the DHCPv6 client does not receive a response from the DHCPv6 server after sending a Renew message at T1, it multicasts a Rebind message to all DHCPv6 servers at T2. Typically, the value of T2 is 0.8 times the preferred lifetime. The DHCPv6 server responds with a Reply message, informing the client whether the lease is renewed. If the DHCPv6 client does not receive a response from any DHCPv6 server before the valid lifetime expires, the client stops using the address/prefix. For more information about the valid lifetime and the preferred lifetime, see IPv6 basics configuration in Layer 3 IP Services Configuration Guide. 184

201 Stateless DHCPv6 Stateless DHCPv6 enables a device that has obtained an IPv6 address/prefix to get other configuration parameters from a DHCPv6 server. The device performs stateless DHCPv6 if an RA message with the following flags is received from the router during stateless address autoconfiguration: The managed address configuration flag (M flag) is set to 0. The other stateful configuration flag (O flag) is set to 1. Figure 58 Stateless DHCPv6 operation As shown in Figure 58, stateless DHCPv6 operates in the following steps: 1. The DHCPv6 client sends an Information-request message to the multicast address of all DHCPv6 servers and DHCPv6 relay agents. The Information-request message contains an Option Request option that specifies the requested configuration parameters. 2. The DHCPv6 server returns to the client a Reply message containing the requested configuration parameters. 3. The client checks the Reply message. If the obtained configuration parameters match those requested in the Information-request message, the client uses these parameters to complete configuration. If not, the client ignores the configuration parameters. If the client receives multiple replies with configuration parameters matching those requested in the Information-request message, it uses the first received reply. DHCPv6 options Option 18 Option 18, also called the interface-id option, is used by the DHCPv6 relay agent to determine the interface to use to forward RELAY-REPLY message. The DHCPv6 snooping device adds Option 18 to the received DHCPv6 request message before forwarding it to the DHCPv6 server. The server then assigns IP address to the client based on the client information in Option

202 Figure 59 Option 18 format Option 37 Figure 59 shows the Option 18 format, which includes the following fields: Option code Option code. The value is 18. Option length Size of the option data. Port index Port that receives the DHCPv6 request from the client. VLAN ID ID of the outer VLAN. Second VLAN ID ID of the inner VLAN. This field is optional. If the received DHCPv6 request does not contain a second VLAN, Option 18 also does not contain it. DUID DUID of the DHCPv6 client. Option 37, also called the remote-id option, is used to identify the client. The DHCPv6 snooping device adds Option 37 to the received DHCPv6 request message before forwarding it to the DHCPv6 server. This option provides client information about address allocation. Figure 60 Option 37 format Figure 60 shows the Option 37 format, which includes the following fields: Option code Option code. The value is 37. Option length Size of the option data. Enterprise number Enterprise number. Port index Port that receives the DHCPv6 request from the client. VLAN ID ID of the outer VLAN. Second VLAN ID ID of the inner VLAN. This field is optional. If the received DHCPv6 request does not contain a second VLAN, Option 37 also does not contain it. DUID DUID of the DHCPv6 client. 186

203 Protocols and standards RFC 3736, Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6 RFC 3315, Dynamic Host Configuration Protocol for IPv6 (DHCPv6) RFC 2462, IPv6 Stateless Address Autoconfiguration RFC 3633, IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6 187

204 Configuring the DHCPv6 server About DHCPv6 server A DHCPv6 server can assign IPv6 addresses, IPv6 prefixes, and other configuration parameters to DHCPv6 clients. IPv6 address assignment As shown in Figure 61, the DHCPv6 server assigns IPv6 addresses, domain name suffixes, DNS server addresses, and other configuration parameters to DHCPv6 clients. The IPv6 addresses assigned to the clients include the following types: Temporary IPv6 addresses Frequently changed without lease renewal. Non-temporary IPv6 addresses Correctly used by DHCPv6 clients, with lease renewal. Figure 61 IPv6 address assignment DHCPv6 client DHCPv6 client DHCPv6 server DHCPv6 client DHCPv6 client IPv6 prefix assignment As shown in Figure 62, the DHCPv6 server assigns an IPv6 prefix to the DHCPv6 client. The client advertises the prefix information in a multicast RA message so that hosts on the subnet can automatically configure their IPv6 addresses by using the prefix. Figure 62 IPv6 prefix assignment 188

205 Concepts Multicast addresses used by DHCPv6 DUID DHCPv6 uses the multicast address FF05::1:3 to identify all site-local DHCPv6 servers. It uses the multicast address FF02::1:2 to identify all link-local DHCPv6 servers and relay agents. A DHCP unique identifier (DUID) uniquely identifies a DHCPv6 device (DHCPv6 client, server, or relay agent). A DHCPv6 device adds its DUID in a sent packet. Figure 63 DUID-LL format IA IAID PD The device supports the DUID format based on link-layer address (DUID-LL) defined in RFC Figure 63 shows the DUID-LL format, which includes the following fields: DUID type The device supports the DUID type of DUID-LL with the value of 0x0003. Hardware type The device supports the hardware type of Ethernet with the value of 0x0001. Link layer address Takes the value of the bridge MAC address of the device. Identified by an IAID, an identity association (IA) provides a construct through which a client manages the obtained addresses, prefixes, and other configuration parameters. A client can have multiple IAs, for example, one for each of its interfaces. An IAID uniquely identifies an IA. It is chosen by the client and must be unique on the client. The DHCPv6 server creates a prefix delegation (PD) for each assigned prefix to record the following details: IPv6 prefix. Client DUID. IAID. Valid lifetime. Preferred lifetime. Lease expiration time. IPv6 address of the requesting client. DHCPv6 address pool The DHCP server selects IPv6 addresses, IPv6 prefixes, and other parameters from an address pool, and assigns them to the DHCP clients. 189

206 Address allocation mechanisms DHCPv6 supports the following address allocation mechanisms: Static address allocation To implement static address allocation for a client, create a DHCPv6 address pool, and manually bind the DUID and IAID of the client to an IPv6 address in the DHCPv6 address pool. When the client requests an IPv6 address, the DHCPv6 server assigns the IPv6 address in the static binding to the client. Dynamic address allocation To implement dynamic address allocation for clients, create a DHCPv6 address pool, specify a subnet for the pool, and divide the subnet into temporary and non-temporary IPv6 address ranges. Upon receiving a DHCP request, the DHCPv6 server selects an IPv6 address from the temporary or non-temporary IPv6 address range based on the address type in the client request. Prefix allocation mechanisms DHCPv6 supports the following prefix allocation mechanisms: Static prefix allocation To implement static prefix allocation for a client, create a DHCPv6 address pool, and manually bind the DUID and IAID of the client to an IPv6 prefix in the DHCPv6 address pool. When the client requests an IPv6 prefix, the DHCPv6 server assigns the IPv6 prefix in the static binding to the client. Dynamic prefix allocation To implement dynamic prefix allocation for clients, create a DHCPv6 address pool and a prefix pool, specify a subnet for the address pool, and apply the prefix pool to the address pool. Upon receiving a DHCP request, the DHCPv6 server dynamically selects an IPv6 prefix from the prefix pool in the address pool. Address pool selection The DHCPv6 server observes the following principles when selecting an IPv6 address or prefix for a client: 1. If there is an address pool where an IPv6 address is statically bound to the DUID or IAID of the client, the DHCPv6 server selects this address pool. It assigns the statically bound IPv6 address or prefix and other configuration parameters to the client. 2. If the receiving interface has an address pool applied, the DHCP server selects an IPv6 address or prefix and other configuration parameters from this address pool. 3. If the receiving interface has a DHCP policy and the DHCP client matches a user class, the DHCP server selects the address pool that is bound to the matching user class. If no matching user class is found, the server assigns an IP address and other parameters from the default DHCP address pool. If no default address pool is specified or the default address pool does not have assignable IP addresses, the address assignment fails. 4. If the above conditions are not met, the DHCPv6 server selects an address pool depending on the client location. Client on the same subnet as the server The DHCPv6 server compares the IPv6 address of the receiving interface with the subnets of all address pools. It selects the address pool with the longest-matching subnet. Client on a different subnet than the server The DHCPv6 server compares the IPv6 address of the DHCPv6 relay agent interface closest to the client with the subnets of all address pools. It also selects the address pool with the longest-matching subnet. To make sure IPv6 address allocation functions correctly, keep the subnet used for dynamic assignment consistent with the subnet where the interface of the DHCPv6 server or DHCPv6 relay agent resides. IPv6 address/prefix allocation sequence The DHCPv6 server selects an IPv6 address/prefix for a client in the following sequence: 1. IPv6 address/prefix statically bound to the client's DUID and IAID and expected by the client. 190

207 2. IPv6 address/prefix statically bound to the client's DUID and IAID. 3. IPv6 address/prefix statically bound to the client's DUID and expected by the client. 4. IPv6 address/prefix statically bound to the client's DUID. 5. IPv6 address/prefix that was ever assigned to the client. 6. Assignable IPv6 address/prefix in the address pool/prefix pool expected by the client. 7. Assignable IPv6 address/prefix in the address pool/prefix pool. 8. IPv6 address/prefix that was a conflict or passed its lease duration. If no IPv6 address/prefix is assignable, the server does not respond. If a client moves to another subnet, the DHCPv6 server selects an IPv6 address/prefix from the address pool that matches the new subnet. Conflicted IPv6 addresses can be assigned to other DHCPv6 clients only after the addresses are in conflict for one hour. DHCPv6 server tasks at a glance Tasks at a glance Perform one of the following tasks at minimum: Configuring IPv6 prefix assignment Configuring IPv6 address assignment Configuring network parameters assignment (Required.) Perform at least one task: Configuring a DHCPv6 policy for IPv6 address and prefix assignment Configuring the DHCPv6 server on an interface (Optional.) Allocating different IPv6 addresses to DHCPv6 clients with the same MAC (Optional.) Setting the DSCP value for DHCPv6 packets sent by the DHCPv6 server (Optional.) Configuring DHCPv6 binding auto backup (Optional.) Advertising subnets assigned to clients (Optional.) Applying a DHCPv6 address pool to a VPN instance (Optional.) Configuring the DHCPv6 server security features (Optional.) Enabling the DHCPv6 server to advertise IPv6 prefixes (Optional.) Enabling DHCPv6 logging on the DHCPv6 server Configuring IPv6 prefix assignment About IPv6 prefix assignment Use the following methods to configure IPv6 prefix assignment: Configure a static IPv6 prefix binding in an address pool If you bind a DUID and an IAID to an IPv6 prefix, the DUID and IAID in a request must match those in the binding before the DHCPv6 server can assign the IPv6 prefix to the DHCPv6 client. If you only bind a DUID to an IPv6 prefix, the DUID in the request must match the DUID in the binding before the DHCPv6 server can assign the IPv6 prefix to the DHCPv6 client. Apply a prefix pool to an address pool The DHCPv6 server dynamically assigns an IPv6 prefix from the prefix pool in the address pool to a DHCPv6 client. 191

208 Restrictions and guidelines Procedure When you configure IPv6 prefix assignment, follow these restrictions and guidelines: An IPv6 prefix can be bound to only one DHCPv6 client. You cannot modify bindings that have been created. To change the binding for a DHCPv6 client, you must delete the existing binding first. Only one prefix pool can be applied to an address pool. You cannot modify prefix pools that have been applied. To change the prefix pool for an address pool, you must remove the prefix pool application first. You can apply a prefix pool that has not been created to an address pool. The setting takes effect after the prefix pool is created. To configure IPv6 prefix assignment: 2. (Optional.) Specify the IPv6 prefixes excluded from dynamic assignment. 3. Create a prefix pool. 4. Create a DHCPv6 address pool and enter its view. 5. Specify an IPv6 subnet for dynamic assignment. ipv6 dhcp server forbidden-prefix start-prefix/prefix-len [ end-prefix/prefix-len ] [ vpn-instance vpn-instance-name ] ipv6 dhcp prefix-pool prefix-pool-number prefix { prefix-number prefix/prefix-len } assign-len assign-len [ vpn-instance vpn-instance-name ] ipv6 dhcp pool pool-name network { prefix/prefix-length prefix prefix-number [ sub-prefix/sub-prefix-length ] } [ preferred-lifetime preferred-lifetime valid-lifetime valid-lifetime ] By default, no IPv6 prefixes in the prefix pool are excluded from dynamic assignment. If the excluded IPv6 prefix is in a static binding, the prefix still can be assigned to the client. To exclude multiple IPv6 prefix ranges, repeat this step. This step is required for dynamic prefix assignment. By default, no prefix pools exist. If you specify an IPv6 prefix by its ID, make sure the IPv6 prefix is in effect. Otherwise, the configuration does not take effect. By default, no DHCPv6 address pools exist. By default, no IPv6 subnet is specified for dynamic assignment. The IPv6 subnets cannot be the same in different address pools. If you specify an IPv6 prefix by its ID, make sure the IPv6 prefix is in effect. Otherwise, the configuration does not take effect. 192

209 6. Configure static prefix assignment, dynamic prefix assignment, or both. Configure a static prefix binding: static-bind prefix prefix/prefix-len duid duid [ iaid iaid ] [ preferred-lifetime preferred-lifetime valid-lifetime valid-lifetime ] Apply the prefix pool to the address pool: prefix-pool prefix-pool-number [ preferred-lifetime preferred-lifetime valid-lifetime valid-lifetime ] By default, static or dynamic prefix assignment is not configured for an address pool. To add multiple static IPv6 prefix bindings, use the static-bind prefix command multiple times. Configuring IPv6 address assignment About IPv6 address assignment Use one of the following methods to configure IPv6 address assignment: Configure a static IPv6 address binding in an address pool. If you bind a DUID and an IAID to an IPv6 address, the DUID and IAID in a request must match those in the binding before the DHCPv6 server can assign the IPv6 address to the requesting client. If you only bind a DUID to an IPv6 address, the DUID in a request must match the DUID in the binding before the DHCPv6 server can assign the IPv6 address to the requesting client. Specify a subnet and address ranges in an address pool. Non-temporary address assignment The server selects addresses from the non-temporary address range specified by the address range command. If no non-temporary address range is specified, the server selects addresses on the subnet specified by the network command. Temporary address assignment The server selects addresses from the temporary address range specified by the temporary address range command. If no temporary address range is specified in the address pool, the DHCPv6 server cannot assign temporary addresses to clients. Restrictions and guidelines Procedure You can specify only one non-temporary address range and one temporary address range in an address pool. The address ranges specified by the address range and temporary address range commands must be on the subnet specified by the network command. Otherwise, the addresses are unassignable. Only one prefix pool can be applied to an address pool. You can apply a prefix pool that has not been created to an address pool. The setting takes effect after the prefix pool is created. An IPv6 address can be bound to only one DHCPv6 client. You cannot modify bindings that have been created. To change the binding for a DHCPv6 client, you must delete the existing binding first. Only one subnet can be specified in an address pool. If you use the network command multiple times in a DHCPv6 address pool, the most recent configuration takes effect. If you use this command to specify only new lifetimes, the settings do not affect existing leases. The IPv6 addresses assigned after the modification will use the new lifetimes. To configure IPv6 address assignment: 193

210 2. (Optional.) Specify the IPv6 addresses excluded from dynamic assignment. 3. Create a DHCPv6 address pool and enter its view. 4. Specify an IPv6 subnet for dynamic assignment. 5. (Optional.) Specify a non-temporary IPv6 address range. 6. (Optional.) Specify a temporary IPv6 address range. 7. (Optional.) Create a static binding. ipv6 dhcp server forbidden-address start-ipv6-address [ end-ipv6-address ] [ vpn-instance vpn-instance-name ] ipv6 dhcp pool pool-name network { prefix/prefix-length prefix prefix-number [ sub-prefix/sub-prefix-length ] } [ preferred-lifetime preferred-lifetime valid-lifetime valid-lifetime ] address range start-ipv6-address end-ipv6-address [ preferred-lifetime preferred-lifetime valid-lifetime valid-lifetime ] temporary address range start-ipv6-address end-ipv6-address [ preferred-lifetime preferred-lifetime valid-lifetime valid-lifetime ] static-bind address ipv6-address/addr-prefix-length duid duid [ iaid iaid ] [ preferred-lifetime preferred-lifetime valid-lifetime valid-lifetime ] By default, all IPv6 addresses except for the DHCPv6 server's IP address in a DHCPv6 address pool are assignable. If the excluded IPv6 address is in a static binding, the address still can be assigned to the client. To exclude multiple IPv6 prefix ranges, repeat this step. By default, no DHCPv6 address pools exist. By default, no IPv6 address subnet is specified. The IPv6 subnets cannot be the same in different address pools. If you specify an IPv6 prefix by its ID, make sure the IPv6 prefix is in effect. Otherwise, the configuration does not take effect. By default, no non-temporary IPv6 address range is specified, and all unicast addresses on the subnet are assignable. By default, no temporary IPv6 address range is specified, and the DHCPv6 server cannot assign temporary IPv6 addresses. By default, no static binding is configured. To add more static bindings, repeat this step. Configuring network parameters assignment In addition to IPv6 prefixes and IPv6 addresses, you can configure the following network parameters in an address pool: A maximum of eight DNS server addresses. One domain name. One address family translation router (AFTR) domain name. A maximum of eight SIP server addresses. A maximum of eight SIP server domain names. You can configure network parameters on a DHCPv6 server by using one of the following methods: Configure network parameters in a DHCPv6 address pool. 194

211 Configure network parameters in a DHCPv6 option group, and specify the option group for a DHCPv6 address pool. Network parameters configured in a DHCPv6 address pool take precedence over those configured in a DHCPv6 option group. Configuring network parameters in a DHCPv6 address pool 2. Create a DHCPv6 address pool and enter its view. 3. Specify an IPv6 subnet for dynamic assignment. 4. Specify a DNS server address. ipv6 dhcp pool pool-name network { prefix/prefix-length prefix prefix-number [ sub-prefix/sub-prefix-length ] } [ preferred-lifetime preferred-lifetime valid-lifetime valid-lifetime ] dns-server ipv6-address By default, no DHCPv6 address pools exist. By default, no IPv6 subnet is specified. The IPv6 subnets cannot be the same in different address pools. If you specify an IPv6 prefix by its ID, make sure the IPv6 prefix is in effect. Otherwise, the configuration does not take effect. By default, no DNS server address is specified. 5. Specify a domain name. domain-name domain-name 6. Specify an AFTR domain name. aftr-name aftr-name By default, no domain name is specified. By default, no AFTR domain name is specified. 7. Specify a SIP server address or domain name. 8. Configure a self-defined DHCPv6 option. sip-server { address ipv6-address domain-name domain-name } option code hex hex-string By default, no SIP server address or domain name is specified. By default, no self-defined DHCPv6 option is configured. Configuring network parameters in a DHCPv6 option group You can create a static DHCPv6 option group by using the ipv6 dhcp option-group command. To create a static DHCPv6 option group: 2. Create a static DHCPv6 option group and enter its view. 3. Specify a DNS server address. 4. Specify a domain name suffix. ipv6 dhcp option-group option-group-number dns-server ipv6-address domain-name domain-name By default, no static DHCPv6 option groups exist. By default, no DNS server address is specified. By default, no domain name suffix is specified. 195

212 5. Specify a SIP server address or domain name. sip-server { address ipv6-address domain-name domain-name } By default, no SIP server address or domain name is specified. 6. Configure a self-defined DHCPv6 option. option code hex hex-string By default, no self-defined DHCPv6 option is configured. 7. Return to system view. quit N/A 8. Create a DHCPv6 address pool and enter its view. 9. Specify a DHCPv6 option group. ipv6 dhcp pool pool-name option-group option-group-number By default, no DHCPv6 address pools exist. By default, no DHCPv6 option group is specified. Configuring a DHCPv6 policy for IPv6 address and prefix assignment About DHCPv6 policy for IPv6 address and prefix assignment In a DHCPv6 policy, each DHCPv6 user class has a bound DHCPv6 address pool. Clients matching different user classes obtain IPv6 addresses, IPv6 prefixes, and other parameters from different address pools. The DHCPv6 policy must be applied to the interface that acts as the DHCPv6 server. When receiving a DHCPv6 request, the DHCPv6 server compares the packet against the user classes in the order that they are configured. If a match is found and the bound address pool has assignable IPv6 addresses or prefixes, the server uses the address pool for assignment. If the bound address pool does not have assignable IPv6 addresses or prefixes, the assignment fails. If no match is found, the server uses the default DHCPv6 address pool for assignment. If no default address pool is specified or the default address pool does not have assignable IPv6 addresses or prefixes, the assignment fails. For successful assignment, make sure the applied DHCPv6 policy and the bound address pools exist. A match rule cannot match an option added by the DHCPv6 device, for example, Option 18 or Option 37. Procedure To configure a DHCPv6 policy for IPv6 address and prefix assignment: 2. Create a DHCPv6 user class and enter DHCPv6 user class view. ipv6 dhcp class class-name By default, no DHCPv6 user classes exist. 3. Configure a match rule for the DHCPv6 user class. if-match rule rule-number { option option-code [ ascii ascii-string [ offset offset partial ] hex hex-string [ mask mask offset offset length length partial ] ] relay-agent gateway-ipv6-address } By default, no match rule is configured for a DHCPv6 user class. 196

213 4. Return to system view. quit N/A 5. Create a DHCPv6 policy and enter DHCPv6 policy view. 6. Specify a DHCPv6 address pool for a DHCPv6 user class. 7. Specify the default DHCPv6 address pool. ipv6 dhcp policy policy-name class class-name pool pool-name default pool pool-name By default, no DHCPv6 policies exist. By default, no address pool is specified for a user class. By default, no default address pool is specified. 8. Return to system view. quit N/A 9. Enter interface view. 10. Apply the DHCPv6 policy to the interface. interface interface-type interface-number ipv6 dhcp apply-policy policy-name N/A By default, no DHCPv6 policy is applied to an interface. Configuring the DHCPv6 server on an interface About DHCPv6 server on an interface Enable the DHCP server and configure one of the following address/prefix assignment methods on an interface: Apply an address pool on the interface The DHCPv6 server selects an IPv6 address/prefix from the applied address pool for a requesting client. If there is no assignable IPv6 address/prefix in the address pool, the DHCPv6 server cannot to assign an IPv6 address/prefix to a client. Configure global address assignment on the interface The DHCPv6 server selects an IPv6 address/prefix in the global DHCPv6 address pool that matches the server interface address or the DHCPv6 relay agent address for a requesting client. If you configure both methods on an interface, the DHCPv6 server uses the specified address pool for address assignment without performing global address assignment. Restrictions and guidelines Procedure When you configure the DHCPv6 server on an interface, follow these restrictions and guidelines: An interface cannot act as a DHCPv6 server and DHCPv6 relay agent at the same time. Do not enable DHCPv6 server and DHCPv6 client on the same interface. If you use the ipv6 dhcp server command multiple times, the most recent configuration takes effect. You can apply an address pool that has not been created to an interface. The setting takes effect after the address pool is created. Only one address pool can be applied to an interface. If you use the ipv6 dhcp server apply pool command multiple times, the most recent configuration takes effect. To configure the DHCPv6 server on an interface: 2. Enter interface view. interface interface-type interface-number N/A 197

214 3. Enable the DHCPv6 server on the interface. 4. Configure an address/prefix assignment method. ipv6 dhcp select server Configure global address assignment: ipv6 dhcp server { allow-hint preference preference-value rapid-commit } * Apply a DHCPv6 address pool to the interface: ipv6 dhcp server apply pool pool-name [ allow-hint preference preference-value rapid-commit ] * By default, the interface discards DHCPv6 packets from DHCPv6 clients. By default, desired address/prefix assignment and rapid assignment are disabled, and the default preference is 0. Allocating different IPv6 addresses to DHCPv6 clients with the same MAC Traditionally, the DHCPv6 server identifies DHCPv6 clients based on their MAC addresses. Each MAC address can be bound to only one IPv6 address. However, DHCPv6 clients that have the same MAC address exist in the network, and each client requires an IPv6 address. You can enable this feature to allocate different IPv6 addresses to such clients. This feature enables the DHCPv6 server to use the following methods to identify the DHCPv6 clients that have the same MAC address: If a DHCPv6 snooping device or a DHCPv6 relay agent exist, you must enable the DHCPv6 snooping device or the DHCPv6 relay agent to support the Interface-ID option. The DHCPv6 server identifies a DHCPv6 client by the MAC address of the client and the Interface-ID option in the DHCPv6 request. If no DHCPv6 snooping device or DHCPv6 relay agent is on the network, the DHCPv6 server identifies a DHCPv6 client by the combination of the following information: The MAC address of the client. The interface name in the DHCPv6 request. The VLAN information of the receiving interface. To allocate different IPv6 addresses to DHCPv6 clients with the same MAC address: 2. Enable allocation of different IPv6 addresses to DHCPv6 clients with the same MAC address. ipv6 dhcp server multi-ip per-mac enable By default, allocation of different IPv6 addresses to DHCPv6 clients with the same MAC address is disabled. Setting the DSCP value for DHCPv6 packets sent by the DHCPv6 server The DSCP value of a packet specifies the priority level of the packet and affects the transmission priority of the packet. 198

215 To set the DSCP value for DHCPv6 packets sent by the DHCPv6 server: 2. Set the DSCP value for DHCPv6 packets sent by the DHCPv6 server. ipv6 dhcp dscp dscp-value By default, the DSCP value in DHCPv6 packets sent by the DHCPv6 server is 56. Configuring DHCPv6 binding auto backup The auto backup feature saves DHCPv6 bindings to a backup file, and allows the DHCPv6 server to download the bindings from the backup file at the server reboot. The bindings include the lease bindings and conflicted IPv6 addresses. They cannot survive a reboot on the DHCPv6 server. The DHCPv6 server does not provide services during the download process. If a connection error occurs during the process and cannot be repaired in a short amount of time, you can terminate the download operation. Manual interruption allows the DHCPv6 server to provide services without waiting for the connection to be repaired. To configure DHCPv6 binding auto backup: 2. Configure the DHCPv6 server to back up the bindings to a file. 3. (Optional.) Manually save the DHCPv6 bindings to the backup file. 4. (Optional.) Set the waiting time after a DHCPv6 binding change for the DHCPv6 server to update the backup file. 5. (Optional.) Terminate the download of DHCPv6 bindings from the backup file. ipv6 dhcp server database filename { filename url url [ username username [ password { cipher simple } string ] ] } ipv6 dhcp server database update now ipv6 dhcp server database update interval interval ipv6 dhcp server database update stop By default, the DHCPv6 server does not back up the DHCPv6 bindings. With this command executed, the DHCPv6 server backs up its bindings immediately and runs auto backup. N/A The default waiting time is 300 seconds. If no DHCPv6 binding changes, the backup file is not updated. N/A Advertising subnets assigned to clients This feature enables the route management module to advertise subnets assigned to DHCPv6 clients. This feature achieves symmetric routing for traffic of the same host. As shown in Figure 64, Router A and Router B act as both the DHCPv6 server and the BRAS device. The BRAS devices send accounting packets to the RADIUS server. To enable the BRAS devices to collect correct accounting information for each RADIUS user, configure the DHCPv6 server to advertise subnets assigned to clients. The upstream and downstream traffic of a RADIUS user will pass through the same BRAS device. 199

216 Figure 64 Network diagram If the address pool is applied to a VPN instance, the VPN instance must exist. To configure the subnet advertisement feature: 2. Create an address pool and enter its view. 3. Advertise the subnet assigned to DHCPv6 clients. ipv6 dhcp pool pool-name network { prefix/prefix-length prefix prefix-number [ sub-prefix/sub-prefix-length ] } [ preferred-lifetime preferred-lifetime valid-lifetime valid-lifetime ] export-route By default, no DHCPv6 address pools exist. By default, the subnet assigned to DHCPv6 clients is not advertised. Applying a DHCPv6 address pool to a VPN instance If a DHCPv6 address pool is applied to a VPN instance, the DHCPv6 server assigns IPv6 addresses in this address pool to clients in the VPN instance. Addresses in this address pool will not be assigned to clients on the public network. The DHCPv6 server can obtain the VPN instance to which a DHCPv6 client belongs from the following information: The client's VPN information stored in authentication modules, such as IPoE. The VPN information of the DHCPv6 server's interface that receives DHCPv6 packets from the client. The VPN information from authentication modules takes priority over the VPN information of the receiving interface. An MCE acting as the DHCP server can assign IP addresses not only to clients on public networks, but also to clients on private networks. The IP address ranges of public and private networks or those of private networks on the DHCP server cannot overlap. For more information about MCE, see MPLS Configuration Guide. To apply a DHCPv6 address pool to a VPN instance: 200

217 2. Create an address pool and enter its view. 3. Apply the address pool to a VPN instance. ipv6 dhcp pool pool-name vpn-instance vpn-instance-name By default, no DHCPv6 address pools exist. By default, the address pool is not applied to any VPN instance. Configuring the DHCPv6 server security features Configuring DHCPv6 flood attack protection About DHCPv6 flood attack protection The DHCPv6 flood attack protection enables the DHCPv6 server to detect DHCPv6 flood attacks according to the DHCPv6 packet rate threshold on a per-mac basis. When the DHCPv6 server receives a DHCPv6 packet from a client (MAC address), it creates a DHCPv6 flood attack entry in check state. If the number of DHCPv6 packets from the same MAC address reaches the upper limit in the detection duration, the server determines that the client is launching a DHCPv6 flood attack. The DHCPv6 flood attack entry changes to the restrain state, and the DHCPv6 server discards the DHCPv6 packets from that client. When the aging time of the entry is reached, the DHCPv6 server deletes the entry. If a DHCPv6 packet from the MAC address arrives later, the DHCPv6 server will create a flood attack entry and count the number of incoming DHCPv6 packets for that client again. This feature is not applicable to a DHCPv6 server if a DHCPv6 relay agent exists in the network. This is because the MAC address of the DHCPv6 relay agent is encapsulated as the source MAC address in the DHCPv6 request received by the DHCPv6 server. In this case, you must configure the feature on the DHCPv6 relay agent. For more information, see "Configuring DHCPv6 flood attack protection." If you configure this feature on an interface having no IPv6 address, this feature does not take effect for packets with multicast destination MAC addresses. Procedure To configure DHCPv6 flood attack protection: 2. Enter interface view. 3. Enable DHCPv6 flood attack protection. interface interface-type interface-number ipv6 dhcp flood-protection enable N/A By default, DHCPv6 flood attack protection is disabled. 4. Return to system view. quit N/A 5. (Optional) Set the DHCPv6 packet rate threshold for DHCPv6 flood attack detection. 6. (Optional) Set the DHCPv6 flood attack entry aging time. ipv6 dhcp flood-protection threshold packet-number milliseconds ipv6 dhcp flood-protection aging-time time By default, the device allows a maximum of 6 DHCPv6 packets per 5000 milliseconds from each DHCPv6 client. The default setting is 300 seconds. 201

218 Enabling the DHCPv6 server to advertise IPv6 prefixes A DHCPv6 client can obtain an IPv6 prefix through DHCPv6 and use this IPv6 prefix to assign IPv6 addresses for clients in a downstream network. If the IPv6 prefix is in a different subnet than the IPv6 address of the DHCPv6 client's upstream interface, the clients in the downstream network cannot access the external network. If the DHCPv6 server is on the same link as the DHCPv6 client, enable the DHCPv6 server to advertise the IPv6 prefix. To enable the DHCPv6 server to advertise IPv6 prefixes: 2. Enable the DHCPv6 server to advertise IPv6 prefixes. ipv6 dhcp advertise pd-route By default, the DHCPv6 server does not advertise IPv6 prefixes. Enabling DHCPv6 logging on the DHCPv6 server The DHCPv6 logging feature enables the DHCPv6 server to generate DHCPv6 logs and send them to the information center. For information about the log destination and output rule configuration in the information center, see Network Management and Monitoring Configuration Guide. As a best practice, disable this feature if the log generation affects the device performance or reduces the address and prefix allocation efficiency. For example, this situation might occur when a large number of clients frequently come online or go offline. To configure DHCPv6 logging on the DHCPv6 server: 2. Enable DHCPv6 logging. ipv6 dhcp log enable By default, DHCPv6 logging is disabled. Display and maintenance commands for DHCPv6 server Execute display commands in any view and reset commands in user view. Task Display the DUID of the local device. Display information about a DHCPv6 option group. Display DHCPv6 address pool information. Display prefix pool information. Command display ipv6 dhcp duid display ipv6 dhcp option-group [ option-group-number ] display ipv6 dhcp pool [ pool-name vpn-instance vpn-instance-name ] display ipv6 dhcp prefix-pool [ prefix-pool-number ] [ vpn-instance vpn-instance-name ] 202

219 Task Display DHCPv6 server information on an interface. Display information about IPv6 address conflicts. Display information about DHCPv6 binding auto backup Display information about expired IPv6 addresses. Display information about IPv6 address bindings. Display information about IPv6 prefix bindings. Display packet statistics on the DHCPv6 server. Clear information about IPv6 address conflicts. Clear information about expired IPv6 address bindings. Clear information about IPv6 address bindings. Clear information about IPv6 prefix bindings. Clear packets statistics on the DHCPv6 server. Command display ipv6 dhcp server [ interface interface-type interface-number ] display ipv6 dhcp server conflict [ address ipv6-address ] [ vpn-instance vpn-instance-name ] display ipv6 dhcp server database display ipv6 dhcp server expired [ [ address ipv6-address ] [ vpn-instance vpn-instance-name ] pool pool-name ] display ipv6 dhcp server ip-in-use [ [ address ipv6-address ] [ vpn-instance vpn-instance-name ] pool pool-name ] display ipv6 dhcp server pd-in-use [ pool pool-name [ prefix prefix/prefix-len ] [ vpn-instance vpn-instance-name ] ] display ipv6 dhcp server statistics [ pool pool-name vpn-instance vpn-instance-name ] reset ipv6 dhcp server conflict [ address ipv6-address ] [ vpn-instance vpn-instance-name ] reset ipv6 dhcp server expired [ [ address ipv6-address ] [ vpn-instance vpn-instance-name ] pool pool-name ] reset ipv6 dhcp server ip-in-use [ [ address ipv6-address ] [ vpn-instance vpn-instance-name ] pool pool-name ] reset ipv6 dhcp server pd-in-use [ pool pool-name [ prefix prefix/prefix-len ] [ vpn-instance vpn-instance-name ] ] reset ipv6 dhcp server statistics [ vpn-instance vpn-instance-name ] DHCPv6 server configuration examples Example: Configuring dynamic IPv6 prefix assignment Network configuration As shown in Figure 65, the router acts as a DHCPv6 server to assign an IPv6 prefix, a DNS server address, a domain name, a SIP server address, and a SIP server name to each DHCPv6 client. The router assigns prefix 2001:0410:0201::/48 to the client whose DUID is CA0006A40000, and assigns prefixes in the range of 2001:0410::/48 to 2001:0410:FFFF::/48 (excluding 2001:0410:0201::/48) to other clients. The DNS server address is 2::2:3. The DHCPv6 clients reside in the domain aaa.com. The SIP server address is 2:2::4, and the SIP server name is bbb.com. 203

220 Figure 65 Network diagram Procedure # Specify an IPv6 address for GigabitEthernet 1/0/1. <Router> system-view [Router] interface gigabitethernet 1/0/1 [Router-GigabitEthernet1/0/1] ipv6 address 1::1/64 # Disable RA message suppression on GigabitEthernet 1/0/1. [Router-GigabitEthernet1/0/1] undo ipv6 nd ra halt # Set the M flag to 1 in RA advertisements to be sent on GigabitEthernet 1/0/1. Hosts that receive the advertisements will obtain IPv6 addresses through DHCPv6. [Router-GigabitEthernet1/0/1] ipv6 nd autoconfig managed-address-flag # Set the O flag to 1 in RA advertisements to be sent on GigabitEthernet 1/0/1. Hosts that receive the advertisements will obtain information other than IPv6 address through DHCPv6. [Router-GigabitEthernet1/0/1] ipv6 nd autoconfig other-flag [Router-GigabitEthernet1/0/1] quit # Create prefix pool 1, and specify the prefix 2001:0410::/32 with assigned prefix length 48. [Router] ipv6 dhcp prefix-pool 1 prefix 2001:0410::/32 assign-len 48 # Create address pool 1. [Router] ipv6 dhcp pool 1 # In address pool 1, specify subnet 1::/64 where the server interface resides. [Router-dhcp6-pool-1] network 1::/64 # Apply prefix pool 1 to address pool 1, and set the preferred lifetime to one day, and the valid lifetime to three days. [Router-dhcp6-pool-1] prefix-pool 1 preferred-lifetime valid-lifetime # In address pool 1, bind prefix 2001:0410:0201::/48 to the client DUID CA0006A40000, and set the preferred lifetime to one day, and the valid lifetime to three days. [Router-dhcp6-pool-1] static-bind prefix 2001:0410:0201::/48 duid CA0006A40000 preferred-lifetime valid-lifetime # Configure the DNS server address as 2:2::3. [Router-dhcp6-pool-1] dns-server 2:2::3 # Configure the domain name as aaa.com. [Router-dhcp6-pool-1] domain-name aaa.com # Configure the SIP server address as 2:2::4, and the SIP server name as bbb.com. [Router-dhcp6-pool-1] sip-server address 2:2::4 204

221 [Router-dhcp6-pool-1] sip-server domain-name bbb.com [Router-dhcp6-pool-1] quit # Enable the DHCPv6 server on GigabitEthernet 1/0/1, enable desired prefix assignment and rapid prefix assignment, and set the preference to the highest. [Router] interface gigabitethernet 1/0/1 [Router-GigabitEthernet1/0/1] ipv6 dhcp select server [Router-GigabitEthernet1/0/1] ipv6 dhcp server allow-hint preference 255 rapid-commit Verifying the configuration # Display the DHCPv6 server configuration on GigabitEthernet 1/0/1. [Router-GigabitEthernet1/0/1] display ipv6 dhcp server interface gigabitethernet 1/0/1 Using pool: global Preference value: 255 Allow-hint: Enabled Rapid-commit: Enabled # Display information about address pool 1. [Router-GigabitEthernet1/0/1] display ipv6 dhcp pool 1 DHCPv6 pool: 1 Network: 1::/64 Preferred lifetime , valid lifetime Prefix pool: 1 Preferred lifetime 86400, valid lifetime Static bindings: DUID: ca0006a4 IAID: Not configured Prefix: 2001:410:201::/48 Preferred lifetime 86400, valid lifetime DNS server addresses: 2:2::3 Domain name: aaa.com SIP server addresses: 2:2::4 SIP server domain names: bbb.com # Display information about prefix pool 1. [Router-GigabitEthernet1/0/1] display ipv6 dhcp prefix-pool 1 Prefix: 2001:410::/32 Assigned length: 48 Total prefix number: Available: In-use: 0 Static: 1 # After the client with the DUID CA0006A40000 obtains an IPv6 prefix, display the binding information on the DHCPv6 server. [Router-GigabitEthernet1/0/1] display ipv6 dhcp server pd-in-use Pool: 1 IPv6 prefix Type Lease expiration 205

222 2001:410:201::/48 Static(C) Jul 10 19:45: # After the other client obtains an IPv6 prefix, display the binding information on the DHCPv6 server. [Router-GigabitEthernet1/0/1] display ipv6 dhcp server pd-in-use Pool: 1 IPv6 prefix Type Lease expiration 2001:410:201::/48 Static(C) Jul 10 19:45: :410::/48 Auto(C) Jul 10 20:44: Example: Configuring dynamic IPv6 address assignment Network configuration As shown in Figure 66, Router A acts as a DHCPv6 server to assign IPv6 addresses to the clients on subnets 1::1:0:0:0/96 and 1::2:0:0:0/96. On Router A, configure the IPv6 address 1::1:0:0:1/96 for GigabitEthernet 1/0/1 and 1::2:0:0:1/96 for GigabitEthernet 1/0/2. The lease duration of the addresses on subnet 1::1:0:0:0/96 is seconds (two days), the valid time is seconds (four days), the domain name is aabbcc.com, and the DNS server address is 1::1:0:0:2/96. The lease duration of the addresses on subnet 1::2:0:0:0/96 is seconds (five days), the valid time is seconds (ten days), the domain name is aabbcc.com, and the DNS server address is 1::2:0:0:2/96. Figure 66 Network diagram Procedure 1. Configure the interfaces on the DHCPv6 server: # Specify an IPv6 address for GigabitEthernet 1/0/1. <RouterA> system-view [RouterA] interface gigabitethernet 1/0/1 [RouterA-GigabitEthernet1/0/1] ipv6 address 1::1:0:0:1/96 # Disable RA message suppression on GigabitEthernet 1/0/1. [RouterA-GigabitEthernet1/0/1] undo ipv6 nd ra halt # Set the M flag to 1 in RA advertisements to be sent on GigabitEthernet 1/0/1. Hosts that receive the advertisements will obtain IPv6 addresses through DHCPv6. [RouterA-GigabitEthernet1/0/1] ipv6 nd autoconfig managed-address-flag # Set the O flag to 1 in RA advertisements to be sent on GigabitEthernet 1/0/1. Hosts that receive the advertisements will obtain information other than IPv6 address through DHCPv6. [RouterA-GigabitEthernet1/0/1] ipv6 nd autoconfig other-flag [RouterA-GigabitEthernet1/0/1] quit 206

223 # Specify an IPv6 address for GigabitEthernet 1/0/2. [RouterA] interface gigabitethernet 1/0/2 [RouterA-GigabitEthernet1/0/2] ipv6 address 1::2:0:0:1/96 # Disable RA message suppression on GigabitEthernet 1/0/2. [RouterA-GigabitEthernet1/0/2] undo ipv6 nd ra halt # Set the M flag to 1 in RA advertisements to be sent on GigabitEthernet 1/0/2. Hosts that receive the advertisements will obtain IPv6 addresses through DHCPv6. [RouterA-GigabitEthernet1/0/2] ipv6 nd autoconfig managed-address-flag # Set the O flag to 1 in RA advertisements to be sent on GigabitEthernet 1/0/2. Hosts that receive the advertisements will obtain information other than IPv6 address through DHCPv6. [RouterA-GigabitEthernet1/0/2] ipv6 nd autoconfig other-flag [RouterA-GigabitEthernet1/0/2] quit 2. Enable DHCPv6: # Enable the DHCPv6 server on the interfaces GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2. [RouterA] interface gigabitethernet 1/0/1 [RouterA-GigabitEthernet1/0/1] ipv6 dhcp select server [RouterA-GigabitEthernet1/0/1] quit [RouterA] interface gigabitethernet 1/0/2 [RouterA-GigabitEthernet1/0/2] ipv6 dhcp select server [RouterA-GigabitEthernet1/0/2] quit # Exclude the DNS server addresses from dynamic assignment. [RouterA] ipv6 dhcp server forbidden-address 1::1:0:0:2 [RouterA] ipv6 dhcp server forbidden-address 1::2:0:0:2 # Create DHCPv6 address pool 1 to assign IPv6 addresses and other configuration parameters to clients on subnet 1::1:0:0:0/96. [RouterA] ipv6 dhcp pool 1 [RouterA-dhcp6-pool-1] network 1::1:0:0:0/96 preferred-lifetime valid-lifetime [RouterA-dhcp6-pool-1] domain-name aabbcc.com [RouterA-dhcp6-pool-1] dns-server 1::1:0:0:2 [RouterA-dhcp6-pool-1] quit # Create DHCPv6 address pool 2 to assign IPv6 addresses and other configuration parameters to clients on subnet 1::2:0:0:0/96. [RouterA] ipv6 dhcp pool 2 [RouterA-dhcp6-pool-2] network 1::2:0:0:0/96 preferred-lifetime valid-lifetime [RouterA-dhcp6-pool-2] domain-name aabbcc.com [RouterA-dhcp6-pool-2] dns-server 1::2:0:0:2 [RouterA-dhcp6-pool-2] quit Verifying the configuration # Verify that clients on subnets 1::1:0:0:0/96 and 1::2:0:0:0/96 can obtain IPv6 addresses and all other configuration parameters from the DHCPv6 server (Router A). (Details not shown.) # On the DHCPv6 server, display IPv6 addresses assigned to the clients. [RouterA] display ipv6 dhcp server ip-in-use 207

224 Configuring the DHCPv6 relay agent About DHCPv6 relay agent Typical application A DHCPv6 client usually uses a multicast address to contact the DHCPv6 server on the local link to obtain an IPv6 address and other configuration parameters. As shown in Figure 67, if the DHCPv6 server resides on another subnet, the DHCPv6 clients need a DHCPv6 relay agent to contact the server. The relay agent feature avoids deploying a DHCPv6 server on each subnet. Figure 67 Typical DHCPv6 relay agent application DHCPv6 client DHCPv6 client IPv6 network DHCPv6 relay agent DHCPv6 client DHCPv6 client DHCPv6 server DHCPv6 relay agent operating process As shown in Figure 68, a DHCPv6 client obtains an IPv6 address and other network configuration parameters from a DHCPv6 server through a DHCPv6 relay agent. The following example uses rapid assignment to describe the process: The DHCPv6 client sends a Solicit message containing the Rapid Commit option to the multicast address FF02::1:2 of all the DHCPv6 servers and relay agents. After receiving the Solicit message, the DHCPv6 relay agent encapsulates the message into the Relay Message option of a Relay-forward message, and sends the message to the DHCPv6 server. After obtaining the Solicit message from the Relay-forward message, the DHCPv6 server performs the following tasks: Selects an IPv6 address and other required parameters. Adds them to a reply that is encapsulated within the Relay Message option of a Relay-reply message. Sends the Relay-reply message to the DHCPv6 relay agent. The DHCPv6 relay agent obtains the reply from the Relay-reply message and sends the reply to the DHCPv6 client. The DHCPv6 client uses the IPv6 address and other network parameters assigned by the DHCPv6 server to complete network configuration. 208

225 Figure 68 Operating process of a DHCPv6 relay agent DHCPv6 client DHCPv6 relay agent DHCPv6 server (1) Solicit (contains a Rapid Commit option) (2) Relay-forward (3) Relay-reply (4) Reply DHCPv6 relay agent tasks at a glance Tasks at a glance (Required.) Enabling the DHCPv6 relay agent on an interface (Required.) Specifying DHCPv6 servers on the relay agent (Optional.) Specifying a gateway address for DHCPv6 clients (Optional.) Setting the DSCP value for DHCPv6 packets sent by the DHCPv6 relay agent (Optional.) Specifying a padding mode for the Interface-ID option (Optional.) Configuring DHCPv6 relay security features (Optional.) Enabling the DHCPv6 relay agent to advertise IPv6 prefixes Enabling the DHCPv6 relay agent on an interface 2. Enter interface view. 3. Enable DHCPv6 relay agent on the interface. interface interface-type interface-number ipv6 dhcp select relay N/A By default, the DHCPv6 relay agent is disabled on the interface. Do not enable the DHCPv6 relay agent and DHCPv6 client on the same interface. Specifying DHCPv6 servers on the relay agent Specifying the DHCPv6 server IP addresses You can use the ipv6 dhcp relay server-address command to specify a maximum of eight DHCPv6 servers on the DHCPv6 relay agent interface. The DHCPv6 relay agent forwards DHCP requests to all the specified DHCPv6 servers. 209

226 To specify a DHCPv6 server on a relay agent: 2. Enter interface view. 3. Specify a DHCPv6 server. interface interface-type interface-number ipv6 dhcp relay server-address ipv6-address [ interface interface-type interface-number ] N/A By default, no DHCPv6 server is specified. If a DHCPv6 server address is a link-local address or multicast address, you must specify an outgoing interface by using the interface keyword in this command. Otherwise, DHCPv6 packets might fail to reach the DHCPv6 server. Specifying DHCPv6 servers for a DHCPv6 address pool on the DHCPv6 relay agent About DHCPv6 servers for a DHCPv6 address pool on the DHCPv6 relay agent This feature allows DHCPv6 clients of the same type to obtain IPv6 addresses, IPv6 prefixes, and other configuration parameters from the DHCPv6 servers in the matching DHCPv6 address pool. It applies to scenarios where the DHCPv6 relay agent connects to clients of the same access type but classified into different types by their locations. In this case, the relay interface typically has no IPv6 address configured. Typical scenario is the IPoE access. You can use the gateway-list command to specify the gateway addresses for clients matching the same DHCPv6 address pool. Upon receiving a DHCPv6 Solicit or Request from a client that matches a DHCPv6 address pool, the relay agent processes the packet as follows: Fills the link-address field of the packet with a specified gateway address. Forwards the packet to all DHCPv6 servers in the matching DHCPv6 address pool. The DHCPv6 servers select a DHCPv6 address pool according to the gateway address. Restrictions and guidelines When you configure this feature, follow these restrictions and guidelines: If this feature is used in the PPPoE scenario, execute the ipv6 dhcp relay client-information record command to enable the DHCPv6 relay agent to record relay entries. When a PPPoE user gets offline, the DHCPv6 relay agent locates the matching relay entry and sends a Release message to the DHCPv6 server. If this feature is used in the PPPoE scenario, you do not need to execute the ipv6 dhcp select relay command. This is because the remote-server command is a must in this configuration task and it implies that this device is a relay device. Procedure To specify DHCPv6 servers for a DHCPv6 address pool on the DHCPv6 relay agent: 2. Create a DHCPv6 address pool and enter its view. ipv6 dhcp pool pool-name By default, no DHCPv6 address pools exist. 210

227 3. Specify gateway addresses for the clients matching the DHCPv6 address pool. gateway-list ipv6-address&<1-8> By default, no gateway address is specified. 4. Specify DHCPv6 servers for the DHCPv6 address pool. remote-server ipv6-address [ interface interface-type interface-number ] By default, no DHCPv6 server is specified for the DHCPv6 address pool. You can specify a maximum of eight DHCPv6 servers for one DHCPv6 address pool for high availability. The relay agent forwards DHCPv6 Solicit and Request packets to all DHCPv6 servers in the DHCPv6 address pool. Specifying a gateway address for DHCPv6 clients By default, the DHCPv6 relay agent fills the link-address field of DHCPv6 Solicit and Request packets with the first IPv6 address of the relay interface. You can specify a gateway address on the relay agent for DHCPv6 clients. The DHCPv6 relay agent uses the specified gateway address to fill the link-address field of DHCPv6 Solicit and Request packets. To specify a gateway address for DHCPv6 clients: 2. Enter interface view. 3. Specify a gateway address for DHCPv6 clients. interface interface-type interface-number ipv6 dhcp relay gateway ipv6-address N/A By default, the DHCPv6 relay agent uses the first IPv6 address of the relay interface as the clients' gateway address. Setting the DSCP value for DHCPv6 packets sent by the DHCPv6 relay agent The DSCP value of a packet specifies the priority level of the packet and affects the transmission priority of the packet. To set the DSCP value for DHCPv6 packets sent by the DHCPv6 relay agent: 2. Set the DSCP value for DHCPv6 packets sent by the DHCPv6 relay agent. ipv6 dhcp dscp dscp-value The default DSCP value is

228 Specifying a padding mode for the Interface-ID option This feature enables the relay agent to fill the Interface-ID option in the specified mode. When receiving a DHCPv6 packet from a client, the relay agent fills the Interface-ID option in the mode and then forwards the packet to the DHCPv6 server. To specify a padding mode for the Interface-ID option: 2. Enter interface view. 3. Specify a padding mode for the Interface-ID option. interface interface-type interface-number ipv6 dhcp relay interface-id { bas interface } N/A By default, the relay agent fills the Interface-ID option with the interface index of the interface. Configuring DHCPv6 relay security features Enabling the DHCPv6 relay agent to record relay entries This feature enables the DHCPv6 relay agent to automatically record DHCPv6 relay entries after DHCPv6 clients obtain IPv6 addresses or prefixes through DHCPv6. A DHCPv6 relay entry contains the binding between a client's hardware address and IPv6 address or prefix. Some security features, such as IP source guard, use DHCPv6 relay entries to check incoming packets and block packets that do not match any entry. Hosts using manually configured IPv6 addresses are denied to access external networks through the relay agent. For more information about IP source guard, see Security Configuration Guide. To enable the DHCPv6 relay agent to record relay entries: 2. Enter interface view. 3. Enable the recording of DHCPv6 relay entries. interface interface-type interface-number ipv6 dhcp relay client-information record N/A By default, the DHCPv6 relay agent does not record relay entries. Enabling IPv6 release notification This feature enables the DHCPv6 relay agent to send a Release message to the DHCPv6 server after it deletes a DHCPv6 relay entry. After the DHCPv6 server receives the message, it reclaims the IPv6 address or prefix and marks the lease as expired. If you do not enable this feature, the DHCPv6 relay agent will not send a Release message after it deletes a relay entry. To enable IPv6 release notification: 212

229 2. Enter interface view. 3. Enable IPv6 release notification. interface interface-type interface-number ipv6 dhcp relay release-agent N/A By default, IPv6 release notification is disabled. Enabling client offline detection This feature enables the DHCPv6 relay agent to detect the status of ND entries. After an ND entry ages out, the DHCPv6 relay agent considers the client offline and deletes the relay entry for the client. For more information about ND, see Layer 3 IP Services Configuration Guide. To enable client offline detection: 2. Enter interface view. interface interface-type interface-number N/A 3. Enable client offline detection. ipv6 dhcp client-detect By default, client offline detection is disabled. Configuring DHCPv6 flood attack protection The DHCPv6 flood attack protection enables the DHCPv6 relay agent to detect DHCPv6 flood attacks according to the DHCPv6 packet rate threshold on a per-mac basis. When the DHCPv6 relay agent receives a DHCPv6 packet from a client (MAC address), it creates a DHCPv6 flood attack entry in check state. If the number of DHCPv6 packets from the same MAC address reaches the upper limit in the detection duration, the relay agent determines that the client is launching a DHCPv6 flood attack. The DHCPv6 flood attack entry changes to the restrain state, and the DHCPv6 relay agent discards the DHCPv6 packets from that client. When the aging time of the entry is reached, the DHCPv6 relay agent deletes the entry. If a DHCPv6 packet from the MAC address arrives later, the DHCPv6 relay agent will create a flood attack entry and count the number of incoming DHCPv6 packets for that client again. To configure DHCPv6 flood attack protection: 2. (Optional) Set the DHCPv6 packet rate threshold for DHCPv6 flood attack detection. 3. (Optional) Set the DHCPv6 flood attack entry aging time. 4. Enter interface view. 5. Enable DHCPv6 flood attack protection. ipv6 dhcp flood-protection threshold packet-number milliseconds ipv6 dhcp flood-protection aging-time time interface interface-type interface-number ipv6 dhcp flood-protection enable By default, the device allows a maximum of 6 DHCPv6 packets per 5000 milliseconds from each DHCPv6 client. The default setting is 300 seconds. N/A By default, DHCPv6 flood attack protection is disabled. 213

230 Enabling the DHCPv6 relay agent to advertise IPv6 prefixes A DHCPv6 client can obtain an IPv6 prefix through DHCPv6 and use this IPv6 prefix to assign IPv6 address to clients in a downstream network. If the IPv6 prefix is in a different subnet than the IPv6 address of the DHCPv6 client's upstream interface, the clients in the downstream network cannot access the external network. You can enable the DHCPv6 relay agent that is on the same link as the DHCPv6 client to advertise the IPv6 prefix. To enable the DHCPv6 relay agent to advertise IPv6 prefixes: 2. Enable the DHCPv6 relay agent to advertise IPv6 prefixes. ipv6 dhcp advertise pd-route By default, the DHCPv6 relay agent does not advertise IPv6 prefixes. Before using this command, make sure the DHCPv6 relay agent is enabled to record DHCPv6 relay entries. Display and maintenance commands for DHCPv6 relay agent Execute display commands in any view and reset commands in user view. Task Display the DUID of the local device. Display DHCPv6 relay entries that record clients' IPv6 address information. Display DHCPv6 relay entries that record clients' IPv6 prefix information. Display DHCPv6 server addresses specified on the DHCPv6 relay agent. Display packet statistics on the DHCPv6 relay agent. Clear DHCPv6 relay entries that record clients' IPv6 address information. Clear DHCPv6 relay entries that record clients' IPv6 prefix information. Clear packets statistics on the DHCPv6 relay agent. Command display ipv6 dhcp duid display ipv6 dhcp relay client-information address [ interface interface-type interface-number ipv6 ipv6-address ] [ vpn-instance vpn-instance-name ] display ipv6 dhcp relay client-information pd [ interface interface-type interface-number prefix prefix/prefix-len ] [ vpn-instance vpn-instance-name ] display ipv6 dhcp relay server-address [ interface interface-type interface-number ] display ipv6 dhcp relay statistics [ interface interface-type interface-number ] reset ipv6 dhcp relay client-information address [ interface interface-type interface-number ipv6 ipv6-address ] [ vpn-instance vpn-instance-name ] reset ipv6 dhcp relay client-information pd [ interface interface-type interface-number prefix prefix/prefix-len ] [ vpn-instance vpn-instance-name ] reset ipv6 dhcp relay statistics [ interface interface-type interface-number ] 214

231 DHCPv6 relay agent configuration examples Example: Configuring DHCPv6 relay agent Network configuration As shown in Figure 69, configure the DHCPv6 relay agent on Router A to relay DHCPv6 packets between DHCPv6 clients and the DHCPv6 server. Router A acts as the gateway of network 1::/64. It sends RA messages to notify the hosts to obtain IPv6 addresses and other configuration parameters through DHCPv6. For more information about RA messages, see IPv6 basics configuration in Layer 3 IP Services Configuration Guide. Figure 69 Network diagram Procedure # Specify IPv6 addresses for GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2. <RouterA> system-view [RouterA] interface gigabitethernet 1/0/2 [RouterA-GigabitEthernet1/0/2] ipv6 address 2::1 64 [RouterA-GigabitEthernet1/0/2] quit [RouterA] interface gigabitethernet 1/0/1 [RouterA-GigabitEthernet1/0/1] ipv6 address 1::1 64 # Disable RA message suppression on GigabitEthernet 1/0/1. [RouterA-GigabitEthernet1/0/1] undo ipv6 nd ra halt # Set the M flag to 1 in RA advertisements to be sent on GigabitEthernet 1/0/1. Hosts that receive the RA messages will obtain IPv6 addresses through DHCPv6. [RouterA-GigabitEthernet1/0/1] ipv6 nd autoconfig managed-address-flag # Set the O flag to 1 in RA advertisements to be sent on GigabitEthernet 1/0/1. Hosts that receive the RA messages will obtain information other than IPv6 address through DHCPv6. [RouterA-GigabitEthernet1/0/1] ipv6 nd autoconfig other-flag # Enable the DHCPv6 relay agent on GigabitEthernet 1/0/1 and specify the DHCPv6 server on the relay agent. [RouterA-GigabitEthernet1/0/1] ipv6 dhcp select relay [RouterA-GigabitEthernet1/0/1] ipv6 dhcp relay server-address 2::2 Verifying the configuration # Display DHCPv6 server address information on Router A. 215

232 [RouterA-GigabitEthernet1/0/1] display ipv6 dhcp relay server-address Interface: GigabitEthernet1/0/1 Server address Outgoing Interface 2::2 # Display packet statistics on the DHCPv6 relay agent. [RouterA-GigabitEthernet1/0/1] display ipv6 dhcp relay statistics Packets dropped : 0 Packets received : 14 Solicit : 0 Request : 0 Confirm : 0 Renew : 0 Rebind : 0 Release : 0 Decline : 0 Information-request : 7 Relay-forward : 0 Relay-reply : 7 Packets sent : 14 Advertise : 0 Reconfigure : 0 Reply : 7 Relay-forward : 7 Relay-reply : 0 216

233 Configuring DHCPv6 snooping About DHCPv6 snooping It guarantees that DHCPv6 clients obtain IP addresses from authorized DHCPv6 servers. Also, it records IP-to-MAC bindings of DHCPv6 clients (called DHCPv6 snooping entries) for security purposes. DHCPv6 snooping defines trusted and untrusted ports to make sure that clients obtain IPv6 addresses only from authorized DHCPv6 servers. Trusted A trusted port can forward DHCPv6 messages correctly to make sure the clients get IPv6 addresses from authorized DHCPv6 servers. Untrusted An untrusted port discards received messages sent by DHCPv6 servers to prevent unauthorized servers from assigning IPv6 addresses. DHCPv6 snooping reads DHCP-ACK messages received from trusted ports and DHCP-REQUEST messages to create DHCPv6 snooping entries. A DHCPv6 snooping entry includes the MAC and IP addresses of a client, the port that connects to the DHCPv6 client, and the VLAN. You can use the display ipv6 dhcp snooping binding command to display the IP addresses of users for management. Application of trusted and untrusted ports Configure ports facing the DHCPv6 server as trusted ports, and configure other ports as untrusted ports. As shown in Figure 70, configure the DHCPv6 snooping device's port that is connected to the DHCPv6 server as a trusted port. The trusted port forwards response messages from the DHCPv6 server to the client. The untrusted port connected to the unauthorized DHCPv6 server discards incoming DHCPv6 response messages. Figure 70 Trusted and untrusted ports 217

234 Restrictions and guidelines: DHCPv6 snooping configuration DHCPv6 snooping works between the DHCPv6 client and server, or between the DHCPv6 client and DHCPv6 relay agent. DHCPv6 snooping does not work between the DHCPv6 server and DHCPv6 relay agent. DHCPv6 snooping tasks at a glance Tasks at a glance (Required.) Configuring basic DHCPv6 snooping (Optional.) Configuring support for Option 18 (Optional.) Configuring support for Option 37 (Optional.) Configuring DHCPv6 snooping entry auto backup (Optional.) Setting the maximum number of DHCPv6 snooping entries (Optional.) Enabling DHCPv6-REQUEST check (Optional.) Configuring a DHCPv6 packet blocking port (Optional.) Enabling DHCPv6 snooping logging Configuring basic DHCPv6 snooping Restrictions and guidelines Follow these guidelines when you configure basic DHCPv6 snooping: To make sure DHCPv6 clients can obtain valid IPv6 addresses, specify the ports connected to authorized DHCPv6 servers as trusted ports. The trusted ports and the ports connected to DHCPv6 clients must be in the same VLAN. If you configure DHCPv6 snooping settings on a Layer 2 Ethernet interface that is a member port of a Layer 2 aggregate interface, the settings do not take effect unless the interface is removed from the aggregation group. Procedure To configure basic DHCPv6 snooping: 2. Enable DHCPv6 snooping. ipv6 dhcp snooping enable By default, DHCPv6 snooping is disabled. 3. Enter interface view. 4. Specify the port as a trusted port. interface interface-type interface-number ipv6 dhcp snooping trust This interface must connect to the DHCPv6 server. By default, all ports are untrusted ports after DHCPv6 snooping is enabled. 5. Return to system view. quit N/A 218

235 6. Enter interface view. 7. (Optional.) Enable recording of client information in DHCPv6 snooping entries. interface interface-type interface-number ipv6 dhcp snooping binding record This interface must connect to the DHCPv6 client. By default, DHCPv6 snooping does not record client information. Configuring support for Option Enter interface view. 3. Enable support for Option 18. interface interface-type interface-number ipv6 dhcp snooping option interface-id enable N/A By default, Option 18 is not supported. Configuring support for Option Enter interface view. 3. Enable support for Option (Optional.) Specify the content as the remote ID. interface interface-type interface-number ipv6 dhcp snooping option remote-id enable ipv6 dhcp snooping option remote-id [ vlan vlan-id ] string remote-id N/A By default, Option 37 is not supported. By default, the DHCPv6 snooping device uses its DUID as the content for Option 37. Configuring DHCPv6 snooping entry auto backup About DHCPv6 snooping entry auto backup The auto backup feature saves DHCPv6 snooping entries to a backup file, and allows the DHCPv6 snooping device to download the entries from the backup file at reboot. The entries on the DHCPv6 snooping device cannot survive a reboot. The auto backup helps the security features provide services if these features (such as IP source guard) must use DHCPv6 snooping entries for user authentication. Restrictions and guidelines Procedure If you disable DHCPv6 snooping with the undo ipv6 dhcp snooping enable command, the device deletes all DHCPv6 snooping entries, including those stored in the backup file. To configure DHCPv6 snooping entry auto backup: 219

236 2. Configure the DHCPv6 snooping device to back up DHCPv6 snooping entries to a file. 3. (Optional.) Manually save DHCPv6 snooping entries to the backup file. 4. (Optional.) Set the waiting time after a DHCPv6 snooping entry change for the DHCPv6 snooping device to update the backup file. ipv6 dhcp snooping binding database filename { filename url url [ username username [ password { cipher simple } string ] ] } ipv6 dhcp snooping binding database update now ipv6 dhcp snooping binding database update interval interval By default, the DHCPv6 snooping device does not back up the DHCPv6 snooping entries. With this command executed, the DHCPv6 snooping device backs up DHCPv6 snooping entries immediately and runs auto backup. This command automatically creates the file if you specify a non-existent file. N/A The default waiting time is 300 seconds. The waiting period starts when a DHCPv6 snooping entry is learned, updated, or removed. The DHCPv6 snooping device updates the backup file when the specified waiting period is reached. All changed entries during the period will be saved to the backup file. If no DHCPv6 snooping entry changes, the backup file is not updated. Setting the maximum number of DHCPv6 snooping entries Perform this task to prevent the system resources from being overused. To set the maximum number of DHCPv6 snooping entries: 2. Enter interface view. 3. Set the maximum number of DHCPv6 snooping entries for the interface to learn. interface interface-type interface-number ipv6 dhcp snooping max-learning-num max-number N/A By default, the number of DHCPv6 snooping entries for an interface to learn is not limited. Enabling DHCPv6-REQUEST check About DHCPv6-REQUEST check Perform this task to use the DHCPv6-REQUEST check feature to protect the DHCPv6 server against DHCPv6 client spoofing attacks. Attackers can forge DHCPv6-RENEW messages to renew leases for legitimate DHCPv6 clients that no longer need the IP addresses. The forged messages disable the victim DHCPv6 server from releasing the IP addresses. Attackers can also forge DHCPv6-DECLINE or DHCPv6-RELEASE messages to terminate leases for legitimate DHCPv6 clients that still need the IP addresses. 220

237 The DHCPv6-REQUEST check feature enables the DHCPv6 snooping device to check every received DHCPv6-RENEW, DHCPv6-DECLINE, or DHCPv6-RELEASE message against DHCPv6 snooping entries. If any criterion in an entry is matched, the device compares the entry with the message information. If they are consistent, the device considers the message valid and forwards it to the DHCPv6 server. If they are different, the device considers the message forged and discards it. If no matching entry is found, the device forwards the message to the DHCPv6 server. Procedure To enable DHCPv6-REQUEST check: 2. Enter interface view. 3. Enable DHCPv6-REQUEST check. interface interface-type interface-number ipv6 dhcp snooping check request-message N/A By default, DHCPv6-REQUEST check is disabled. Configuring a DHCPv6 packet blocking port Perform this task to configure a port as a DHCPv6 packet blocking port. The DHCPv6 packet blocking port drops all incoming DHCP requests. To configure a DHCPv6 packet blocking port: 2. Enter interface view. 3. Configure the port to block DHCPv6 requests. interface interface-type interface-number ipv6 dhcp snooping deny N/A By default, the port does not block DHCPv6 requests. Enabling DHCPv6 snooping logging The DHCPv6 snooping logging feature enables the DHCPv6 snooping device to generate DHCPv6 snooping logs and send them to the information center. For information about the log destination and output rule configuration in the information center, see Network Management and Monitoring Configuration Guide. As a best practice, disable this feature if the log generation affects the device performance. To enable DHCPv6 snooping logging: 2. Enable DHCPv6 snooping logging. ipv6 dhcp snooping log enable By default, DHCPv6 snooping logging is disabled. 221

238 Display and maintenance commands for DHCPv6 snooping Execute display commands in any view, and reset commands in user view. Task Display information about trusted ports. Display DHCPv6 snooping entries. Display information about the file that stores DHCPv6 snooping entries. (In standalone mode.) Display DHCPv6 packet statistics for DHCPv6 snooping. (In IRF mode.) Display DHCPv6 packet statistics for DHCPv6 snooping. Clear DHCPv6 snooping entries. (In standalone mode.) Clear DHCPv6 packet statistics for DHCPv6 snooping. (In IRF mode.) Clear DHCPv6 packet statistics for DHCPv6 snooping. Command display ipv6 dhcp snooping trust display ipv6 dhcp snooping binding [ address ipv6-address [ vlan vlan-id ] ] display ipv6 dhcp snooping binding database display ipv6 dhcp snooping packet statistics [ slot slot-number ] display ipv6 dhcp snooping packet statistics [ chassis chassis-number slot slot-number ] reset ipv6 dhcp snooping binding { all address ipv6-address [ vlan vlan-id ] } reset ipv6 dhcp snooping packet statistics [ slot slot-number ] reset ipv6 dhcp snooping packet statistics [ chassis chassis-number slot slot-number ] Example: Configuring DHCPv6 snooping Network configuration As shown in Figure 71, Switch B is connected to the authorized DHCPv6 server through GigabitEthernet 1/0/1, to the unauthorized DHCPv6 server through GigabitEthernet 1/0/3, and to the DHCPv6 client through GigabitEthernet 1/0/2. Configure only the port connected to the authorized DHCPv6 server to forward the responses from the DHCPv6 server. Enable the DHCPv6 snooping device to record client information in DHCPv6 snooping entries. 222

239 Figure 71 Network diagram Procedure # Enable DHCPv6 snooping. <SwitchB> system-view [SwitchB] ipv6 dhcp snooping enable # Specify GigabitEthernet 1/0/1 as a trusted port. [SwitchB] interface gigabitethernet 1/0/1 [SwitchB-GigabitEthernet1/0/1] ipv6 dhcp snooping trust [SwitchB-GigabitEthernet1/0/1] quit # Enable the recording of DHCPv6 snooping entries on GigabitEthernet 1/0/2. [SwitchB]interface gigabitethernet 1/0/2 [SwitchB-GigabitEthernet1/0/2] ipv6 dhcp snooping binding record [SwitchB-GigabitEthernet1/0/2] quit Verifying the configuration # Verify that the DHCPv6 client obtains an IPv6 address and all other configuration parameters only from the authorized DHCPv6 server. (Details not shown.) # Display DHCPv6 snooping entries on the DHCPv6 snooping device. [SwitchB] display ipv6 dhcp snooping binding 223

240 Configuring ITA About ITA Intelligent Target Accounting (ITA) provides a flexible accounting solution for users that request services of different charge rates. By defining different traffic levels based on the destination addresses of users' traffic, you can use ITA to separate the traffic accounting statistics of different levels for each user. ITA services are supported only for portal, IPoE, and PPP users. You must deploy an ITA policy to implement ITA services. Restrictions: Hardware compatibility with ITA ITA is supported only on CSPEX cards. Restrictions and guidelines: ITA configuration For dual-stack PPPoE users, the stack for a level of ITA traffic must be the same as the actual stack of the traffic that matches the level. For dual-stack PPPoE users, you cannot specify the same ITA traffic level for IPv4 ITA traffic and IPv6 ITA traffic. If you specify the same ITA traffic level for IPv4 ITA traffic and IPv6 ITA traffic, the most recent configuration takes effect. The device does not perform accounting on ITA traffic if you do not specify the ipv4 or ipv6 keyword in the accounting-level command. Supported traffic levels for ITA accounting vary by the access types of users, as shown in Table 11. Table 11 ITA traffic accounting levels for different user types User type Portal users that access the network through VLAN interfaces Portal users that access the network through the following types of interfaces: Layer 3 Ethernet interface. Layer 3 Ethernet subinterface. Layer 3 aggregate interface. Layer 3 aggregate subinterface. Number of ITA traffic accounting levels CSPEX-1204 card CSPEX cards (excluding the CSPEX-1204 card) 7 (level-1 to level 8) 7 (level-1 to level 8) 1 (level-1) 4 (level 1 to level 4) IPoE users. 1 (level-1) 4 (level 1 to level 4) PPPoE users 1 (level-1) 4 (level 1 to level 4) ITA tasks at a glance To deploy an ITA policy, perform the following tasks: 224

241 1. Configure a QoS policy to remark traffic destined for different IP addresses or subnets to different levels. For more information about QoS, see ACL and QoS Configuration Guide. 2. Apply the QoS policy. For ITA to operate correctly, choose only one of the following methods: Apply the QoS policy globally or to interfaces. This method is not applicable to portal users that access the network through VLAN interfaces. Configure a user profile, apply the QoS policy to the user profile, and authorize the user profile to authenticated users. Two methods are available for authorizing the user profile to authenticated users. You can configure a remote server or the device to assign the user profile or specify the user profile in the authentication domain. The user profile assigned by a remote server or the device takes precedence over the user profile specified in the authentication domain. For more information about user profiles, see "Configuring user profiles." 3. Configuring an ITA policy. 4. Apply the ITA policy to authenticated users. The following methods are available: Use a RADIUS server to assign the ITA policy. Specify the ITA policy in the authentication domain. The ITA policy assigned by a RADIUS server takes precedence over the ITA policy specified in the authentication domain. You can configure accounting methods for an ITA policy. ITA accounting is separated from accounting of other services. However, you can configure the device to include the amount of ITA traffic in the overall traffic statistics sent to the accounting server. Configuring an ITA policy 2. Create an ITA policy and enter ITA policy view. ita policy policy-name By default, no ITA policies exist. 3. Specify accounting methods in the ITA policy. 4. Specify a traffic level for ITA accounting. 5. (Optional.) Enable accounting merge. 6. (Optional.) Configure access control for users that have used up their ITA data quotas. 7. (Optional.) Exclude the amount of specific-level ITA traffic from the overall traffic statistics that are sent to the accounting server. accounting-method { none radius-scheme radius-scheme-name [ none ] } accounting-level level { { ipv4 ipv6 } car { inbound cir committed-information-rate [ pir peak-information-rate ] outbound cir committed-information-rate [ pir peak-information-rate ] } * } * accounting-merge enable traffic-quota-out { offline online } traffic-separate enable [ level level&<1-8> ] By default, the accounting method is none. By default, no traffic levels are specified for ITA accounting. By default, accounting merge is disabled. By default, the users cannot access the authorized IP subnets after they use up their ITA data quotas. By default, the amount of ITA traffic is included in the overall traffic statistics that are sent to the accounting server. 225

242 Display and maintenance commands for ITA Execute display commands in any view. Task Command Display ITA policy information. display ita policy [ policy-name ] ITA configuration examples Example: Configuring ITA for IPoE users IMPORTANT: This configuration example is supported only on CSPEX cards. Network configuration As shown in Figure 72, the router performs IPoE authentication. Configure the router to meet the following requirements: Use RADIUS server 1 to perform authentication, authorization, and accounting for IPoE users. Use RADIUS server 2 to perform ITA accounting for IPoE users. The traffic destined for the FTP server is configured as level 1 traffic. The router counts the traffic as IPv4 traffic. Exclude ITA traffic statistics from the overall traffic statistics reported to RADIUS server 1. Prohibit users from accessing the FTP server after their level-1 data quotas are used up. Figure 72 Network diagram Procedure 1. Configure RADIUS server 1 and RADIUS server 2: This example uses FreeRADIUS servers. # Configure the clients.conf file. client /32 { ipaddr = netmask=32 secret=radius } 226

243 client /32 { ipaddr = netmask=32 secret=radius } # Configure the IP address of the user and the authorized user profile in the users file Cleartext-Password :="radius" Filter-Id :="profile1" 2. Configure the router: a. Configure the IP address of each interface, as shown in Figure 72. (Details not shown.) b. Configure a RADIUS scheme for AAA: # Create a RADIUS scheme named rs1 and enter RADIUS scheme view. <Router> system-view [Router] radius scheme rs1 # Specify the primary RADIUS authentication server at [Router-radius-rs1] primary authentication # Specify the primary RADIUS accounting server at [Router-radius-rs1] primary accounting # Set the authentication shared key to radius in plaintext form for secure communication between the router and RADIUS server 1. [Router-radius-rs1] key authentication simple radius # Set the accounting shared key to radius in plaintext form for secure communication between the router and RADIUS server 1. [Router-radius-rs1] key accounting simple radius # Exclude domain names from the usernames sent to RADIUS server 1. [Router-radius-rs1] user-name-format without-domain [Router-radius-rs1] quit c. Configure a RADIUS scheme for the ITA service: # Create a RADIUS scheme named rs2 and enter RADIUS scheme view. [Router] radius scheme rs2 # Specify the primary accounting server at [Router-radius-rs2] primary accounting # Set the accounting shared key to radius in plaintext form for secure communication between the router and RADIUS server 2. [Router-radius-rs2] key accounting simple radius # Exclude domain names from the usernames sent to RADIUS server 2. [Router-radius-rs1] user-name-format without-domain [Router-radius-rs1] quit d. Configure a QoS policy for the ITA service: # Configure IPv4 advanced ACL 3000 and enter its view. [Router] acl advanced 3000 # Permit all packets destined for [Router-acl-ipv4-3000] rule 0 permit ip destination [Router-acl-ipv4-3000] quit # Create a traffic class named classifier_1. [Router] traffic classifier classifier_1 # Define a match criterion for traffic class classifier_1 to match advanced ACL

244 [Router-classifier-classifier_1] if-match acl 3000 [Router-classifier-classifier_1] quit # Create a traffic behavior named behavior_1 and enter traffic behavior view. [Router] traffic behavior behavior_1 # Mark level-1 traffic for ITA accounting. [Router-behavior-behavior_1] remark account-level 1 # Measure the traffic in bytes. [Router-behavior-behavior_1] accounting byte [Router-behavior-behavior_1] quit # Define a QoS policy named policy and enter QoS policy view. [Router] qos policy policy # Associate traffic class classifier_1 with traffic behavior behavior_1 in the QoS policy. [Router-qospolicy-policy] classifier classifier_1 behavior behavior_1 [Router-qospolicy-policy] quit e. Configure a user profile for the ITA service: # Create a user profile named profile1 and enter user profile view. [Router] user-profile profile1 # Apply QoS policy policy to the inbound traffic of the users associated with the user profile. [Router-user-profile-profile1] qos apply policy policy inbound [Router-user-profile-profile1] quit f. Configure an ITA policy: # Create an ITA policy named ita and enter ITA policy view. [Router] ita policy ita # Configure the accounting method for users that match the ITA policy. [Router-ita-policy-ita] accounting-method radius-scheme rs2 # Specify level-1 traffic for ITA accounting and count the traffic as IPv4 traffic. [Router-ita-policy-ita] accounting-level 1 ipv4 # Exclude the amount of ITA traffic from the overall traffic statistics that are sent to RADIUS server 1. [Router-ita-policy-ita] traffic-separate enable # Prohibit users from accessing the authorized IP subnets after their ITA data quotas are used up. [Router-ita-policy-ita] traffic-quota-out offline [Router-ita-policy-ita] quit g. Configure an ISP domain: # Create an ISP domain named dm1 and enter ISP domain view. [Router] domain dm1 # Configure the authentication, authorization, and accounting methods for IPoE users in the domain. [Router-isp-dm1] authentication ipoe radius-scheme rs1 [Router-isp-dm1] authorization ipoe radius-scheme rs1 [Router-isp-dm1] accounting ipoe radius-scheme rs1 # Apply ITA policy ita to the ISP domain. [Router-isp-dm1] ita-policy ita [Router-isp-dm1] quit h. Configure IPoE: # Enter the view of GigabitEthernet 1/0/1. 228

245 [Router] interface gigabitethernet 1/0/1 # Enable IPoE and configure Layer 3 access mode on the port. [Router GigabitEthernet1/0/1] ip subscriber routed enable # Enable the unclassified-ip users. [Router GigabitEthernet1/0/1] ip subscriber initiator unclassified-ip enable # Specify dm1 as the ISP domain. [Router GigabitEthernet1/0/1] ip subscriber unclassified-ip domain dm1 # Set the password to radius in plaintext form for IPoE authentication. [Router GigabitEthernet1/0/1] ip subscriber password plaintext radius [Router GigabitEthernet1/0/1] quit Verifying the configuration # Use password radius to pass IPoE authentication on the host. (Details not shown.) # Verify that RADIUS server 2 performs accounting for the IPoE user when the user accesses the FTP server at (Details not shown.) # Verify that RADIUS server 1 performs accounting for the non-ita traffic of the IPoE user. (Details not shown.) # Display detailed information about the sessions of online IPoE users. Verify that the user is assigned the user profile and has generated ITA traffic statistics. <Router> display ip subscriber session verbose 229

246 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 in the following scenarios: Resource allocation per user 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. User access control When a user passes authentication but the account is overdue, only the resources defined by the ACL permit rules in the free rules are accessible for this user. Prerequisites Before configuring a user profile, you must complete the authentication configuration. To determine whether an authentication method supports user profiles, see the configuration guide for the authentication module. Restrictions and guidelines: User profile configuration Only SPC, CSPC, and CMPE-1104 cards support user profiles. Configuring a user profile for a single user A user profile works with authentication methods. You must configure authentication for a user profile. You can also specify a queue for session packets that use the user profile. To limit online users, you must configure a feature, such as a CAR policy, for the user profile. To configure a user profile for a single user: 2. Create a user profile and enter user profile view. user-profile profile-name By default, no user profiles exist. You can use the command to enter the view of an existing user profile. 230

247 3. Configure the user profile. Apply a QoS policy to the user profile: qos apply policy policy-name { inbound outbound } 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 ] Set the maximum number of user connections: connection-limit amount amount Set the maximum connection establishment rate: connection-limit rate rate For more information about QoS policy and CAR configuration, see ACL and QoS Configuration Guide. For more information about connection limit configuration, see "Configuring connection limits." 4. (Optional.) Specify a queue for session packets that use the user profile. 5. (Optional.) Create a user profile free rule. qos queue { queue-id queue-name } free-rule acl [ ipv6 ] { acl-number name acl-name } By default, no queue exists for saving session packets for a user profile. Session packets are scheduled based on the scheduling priority that the specified queue has. By default, no user profile free rules exist. Configuring a user profile for a user group NOTE: Support for this feature depends on the device model. A session group profile is a particular type of user profile for a group of users. It implements QoS traffic control on a per-group basis. A user group can include multiple users and multiple services. For example, you can configure a session group profile to limit the total bandwidth for the user group in addition to configuring a user profile for each user. After user profiles for user groups are deployed, the device identifies different user groups by sessions and associates each user group with a user profile. To configure a user profile for a user group: 2. Enter interface view. interface interface-type interface-number N/A 231

248 3. Identify a session group on the interface. qos session-group identify { customer-vlan service-vlan customer-service-vlan subscriber-id } 4. Return to system view. quit N/A By default, no session group is identified on the interface. 5. Create a session group profile and enter session group profile view. 6. Configure the session group profile. user-profile profile-name type session-group Configure GTS for the session group profile: qos gts [ inbound ] { any queue queue-id } cir committed-information-rate [ cbs committed-burst-size [ ebs excess-burst-size ] ] [ queue-length queue-length ] qos gts [ inbound ] { any queue queue-id } cir committed-information-rate [ cbs committed-burst-size ] pir peak-information-rate [ ebs excess-burst-size ] [ queue-length queue-length ] Apply a queue scheduling profile to the session group profile: qos apply qmprofile [ four-queue ] profile-name [ inbound ] By default, no session group profiles exist. You can use the command to enter the view of an existing session group profile. For more information, see ACL and QoS Configuration Guide. Display and maintenance commands for user profiles Execute display commands in any view. Task (In standalone mode.) Display configuration and online user information for the specified user profile or all user profiles. (In IRF mode.) Display configuration and online user information for the specified user profile or all user profiles. Command display user-profile [ session-group ] [ name profile-name ] [ slot slot-number ] display user-profile [ session-group ] [ name profile-name ] [ chassis chassis-number slot slot-number ] 232

249 Configuring connection limits (interface-based) About connection limits The connection limit feature enables the device to monitor and limit the number of established connections. As shown in Figure 73, configure the connection limit feature to resolve the following issues: If Host B initiates a large number of connections in a short period of time, it might exhaust system resources and cause Host A to be unable to access the Internet. If the internal server receives a large number of connection requests in a short period of time, the server cannot process other requests. Figure 73 Network diagram Restrictions: Hardware compatibility with connection limits configuration This feature is available on the CSPEX cards. Connection limit tasks at a glance Tasks at a glance (Required.) Creating a connection limit policy (Required.) Configuring the connection limit policy (Required.) Applying the connection limit policy Creating a connection limit policy A connection limit policy contains a set of connection limit rules, each of which defines a range of connections and the criteria for limiting the connections. To create a connection limit policy: 233

250 2. Create a connection limit policy and enter its view. connection-limit { ipv6-policy policy } policy-id By default, no connection limit policies exist. Configuring the connection limit policy About connection limit policies To use a connection limit policy, you need to add limit rules to the policy. Each rule defines a range of connections and the criteria for limiting the connections. Connections in the range will be limited based on the criteria. When the number of matching connections reaches the upper limit, the device does not accept new connections until the number of connections drops below the lower limit. The device will send logs when the number of connections exceeds the upper limit and when the number of connections drops below the lower limit. The connections that do not match any connection limit rules are not limited. In each connection limit rule, an ACL is used to define the connection range. In addition, the rule also uses the following filtering methods to further limit the connections: per-destination Limits user connections by destination IP address. per-service Limits user connections by service (transport layer protocol and service port). per-source Limits user connections by source IP address. You can select more than one filtering method, and the selected methods take effect at the same time. For example, if you specify both per-destination and per-service, the user connections using the same service and destined to the same IP address are limited. If you do not specify any filtering methods in a limit rule, all user connections in the range are limited. Restrictions and guidelines for connection limit policy configuration When a connection limit policy is applied, connections on the device match all limit rules in the policy in ascending order of rule IDs. As a best practice, specify a smaller range and more filtering methods in a rule with a smaller ID. The connections are limited on a per-interface module basis. Configuring an IPv4 connection limit policy 2. Create an IPv4 connection limit policy and enter its view. connection-limit policy policy-id N/A 3. Configure a connection limit rule. limit limit-id acl { acl-number name acl-name } [ per-destination per-service per-source ] * amount max-amount min-amount By default, no connection limit rules exist. 234

251 4. (Optional.) Configure a description for the connection limit policy. description text By default, an IPv4 connection limit policy does not have a description. Configuring an IPv6 connection limit policy 2. Create an IPv6 connection limit policy and enter its view. 3. Configure a connection limit rule. 4. (Optional.) Configure a description for the connection limit policy. connection-limit ipv6-policy policy-id limit limit-id acl ipv6 { acl-number name acl-name } [ per-destination per-service per-source ] * amount max-amount min-amount description text N/A By default, no connection limit rules exist. By default, an IPv6 connection limit policy does not have a description. Applying the connection limit policy About connection limit application To make a connection limit policy take effect, apply it globally. The connection limit policy applied globally takes effect on all the specified connections on the device. Restrictions and guidelines A connection limit policy takes effect only on new connections. It does not take effect on existing connections. On an IRF fabric where session synchronization is enabled, connection limit policies applied to a subordinate device do not take effect on sessions switched from the master device. Procedure To apply a connection limit policy globally: 2. Apply a connection limit policy globally. connection-limit apply global { ipv6-policy policy } policy-id By default, no connection limit is applied globally. Only one IPv4 connection limit policy and one IPv6 connection limit policy can be applied globally. A new IPv4 or IPv6 connection limit policy overwrites the old policy. 235

252 Display and maintenance commands for connection limits Execute display commands in any view and reset commands in user view. Task Display the connection limit policy information. (In standalone mode.) Display the connection limit statistics globally or on an interface. (In IRF mode.) Display the connection limit statistics globally or on an interface. (In standalone mode.) Display statistics about connections matching connection limit rules globally or on an interface. (In IRF mode.) Display statistics about connections matching connection limit rules globally or on an interface. (In standalone mode.) Clear the connection limit statistics globally or on an interface. (In IRF mode.) Clear the connection limit statistics globally or on an interface. Command display connection-limit { ipv6-policy policy } { all policy-id } display connection-limit statistics { global interface interface-type interface-number } [ slot slot-number ] display connection-limit statistics { global interface interface-type interface-number } [ chassis chassis-number slot slot-number ] display connection-limit { ipv6-stat-nodes stat-nodes } { global interface interface-type interface-number } [ slot slot-number ] [ destination destination-ip service-port port-number source source-ip ] * [ count ] display connection-limit { ipv6-stat-nodes stat-nodes } { global interface interface-type interface-number } [ chassis chassis-number slot slot-number ] [ destination destination-ip service-port port-number source source-ip ] * [ count ] reset connection-limit statistics { global interface interface-type interface-number } [ slot slot-number ] reset connection-limit statistics { global interface interface-type interface-number } [ chassis chassis-number slot slot-number ] Troubleshooting connection limits ACLs in the connection limit rules with overlapping segments Symptom A connection limit policy has two rules. Rule 1 sets the upper limit to 10 for the connections from each host on segment /24. Rule 2 sets the upper limit to 100 for the connections from /24. <Device> system-view [Device] acl basic 2001 [Device-acl-ipv4-basic-2001] rule permit source [Device-acl-ipv4-basic-2001] quit [Device] acl basic 2002 [Device-acl-ipv4-basic-2002] rule permit source [Device-acl-ipv4-basic-2002] quit [Device] connection-limit policy 1 [Device-connection-limit-policy-1] limit 1 acl 2001 per-destination amount 10 5 [Device-connection-limit-policy-1] limit 2 acl 2002 per-destination amount

253 Solution As a result, the host at can only initiate a maximum of 10 connections to the external network. To resolve the issue: 1. Rearrange the two connection limit rules by exchanging their rule IDs. 2. If the issue persists, contact H3C Support. 237

254 Configuring connection limits (user profile-based) About connection limits The connection limit feature enables the device to assign user profiles to control the number of established connections and establishment rate on a per-user basis. This feature facilitates accurate allocation of system resources and improves access efficiency when multiple users are present. After the user passes authentication, the device checks the associated user profile, and performs either of the following actions: If the user profile exists and has a connection limit policy in its view, the device restricts user access according to the connection limit policy. If no user profile exists or the user profile does not have a connection limit policy, the device allows user access without limiting the connections initiated by the user. As shown in Figure 74, configure the connection limit feature to resolve the following issues: If Host B initiates a large number of connections in a short period of time, it might exhaust system resources and cause Host A to be unable to access the Internet. If the internal server receives a large number of connection requests in a short period of time, the server cannot process other requests. Figure 74 Network diagram Restrictions: Hardware compatibility with connection limits configuration This feature is available on the CSPEX cards. Prerequisites for connection limits The connection limit feature must work with an authentication server. Before configuring connection limits, complete either of the following tasks: For remote authentication, specify the user profile to be associated with the user's account on the remote server. 238

255 For local authentication, specify the user's authorized user profile in local user view on the device. For information about configuring local users, see AAA BRAS Services Configuration Guide. Configuring connection limits 2. Create a user profile and enter user profile view. 3. Set the maximum number of user connections. 4. Set the maximum connection establishment rate. 5. (Optional.) Display user profile configuration and online user information. user-profile profile-name connection-limit amount amount connection-limit rate rate In standalone mode: display user-profile [ name profile-name ] [ slot slot-number ] In IRF mode: display user-profile [ name profile-name ] [ chassis chassis-number slot slot-number ] If the user profile already exists, you directly enter user profile view. Settings in user profile view take effect only after the user profile is issued successfully. For information about this command, see user profile commands in BRAS Services Command Reference. By default, the number of user connections is not limited. By default, the connection establishment rate is not limited. For information about this command, see user profile commands in BRAS Services Command Reference. Connection limit configuration examples Example: Configuring connection limits Network configuration As shown in Figure 75, all users must pass AAA authentication before they can access the public network. To ensure higher priority for Teacher A's connections than students' connections, perform the following tasks on the device: Limit Teacher A to establish a maximum of 100 connections to the public network. Limit each student to establish a maximum of 10 connections to the public network. 239

256 Figure 75 Network diagram Procedure 1. Configure the AAA server. # Configure accounts for the teacher and the students. Specify the associated user profile names of the teacher and the students as teacher and student, respectively. (Details not shown.) 2. Configure the device. # Configure AAA authentication. (Details not shown.) # Create user profile teacher, and set the maximum number of connections to 100. <Device> system-view [Device] user-profile teacher [Device-user-profile-teacher] connection-limit amount 100 [Device-user-profile-teacher] quit # Create user profile student, and set the maximum number of connections to 10. [Device] user-profile student [Device-user-profile-student] connection-limit amount 10 [Device-user-profile-student] quit Verifying the configuration # Display configuration information about the user profile-based connection limits. [Device] display user-profile User-Profile: teacher Connection-limit amount: 100 User-Profile: student Connection-limit amount: 10 The output shows that the teacher and students can establish only 100 and 10 connections, respectively, to the public network after they pass authentication. 240

257 Configuring L2TP About L2TP The Layer 2 Tunneling Protocol (L2TP) is a Virtual Private Dialup Network (VPDN) tunneling protocol. L2TP sets up point-to-point tunnels across a public network (for example, the Internet) and transmits encapsulated PPP frames (L2TP packets) over the tunnels. With L2TP, remote users can access the private networks through L2TP tunnels after connecting to a public network by using PPP. As a Layer 2 VPN technology, L2TP provides a secure, cost-effective solution for remote users to access private networks. Typical L2TP networking Figure 76 L2TP network diagram As shown in Figure 76, a typical L2TP network has the following components: Remote system A remote system is usually a remote user's host or a remote branch's device that needs to access the private network. LAC An L2TP access concentrator (LAC) is both PPP and L2TP capable. It is usually a network access server (NAS) located at a local ISP, which provides access services mainly for PPP users. An LAC is an endpoint of an L2TP tunnel and lies between an LNS and a remote system. It encapsulates packets received from a remote system by using L2TP and then sends the encapsulated packets to the LNS. It decapsulates packets received from the LNS and then sends the decapsulated packets to the intended remote system. LNS An L2TP network server (LNS) is both PPP and L2TP capable. It is usually an edge device on an enterprise network. An LNS is the other endpoint of an L2TP tunnel. It is the logical termination point of a PPP session tunneled by the LAC. L2TP extends the termination point of a PPP session from a NAS to an LNS by establishing a tunnel. L2TP message types and encapsulation structure L2TP uses the following types of messages: 241

258 Control messages Used to establish, maintain, and delete L2TP tunnels and sessions. Control messages are transmitted over a reliable control channel, which supports flow control and congestion control. Data messages Used to encapsulate PPP frames, as shown in Figure 77. Data messages are transmitted over an unreliable data channel and are not retransmitted when packet loss occurs. Data messages can use sequence numbers to reorder packets that are disordered during transport. Figure 77 Data message format As shown in Figure 78, both control messages and data messages are encapsulated in UDP datagrams. Figure 78 L2TP encapsulation structure L2TP tunnel and session An L2TP tunnel is a virtual point-to-point connection between an LAC and an LNS. Multiple L2TP tunnels can be established between an LNS and an LAC. An L2TP tunnel can carry one or more L2TP sessions. Each L2TP session corresponds to a PPP session and is multiplexed on an L2TP tunnel. An L2TP session is established between the LAC and LNS when an end-to-end PPP session is established between a remote system and the LNS. Data frames for the PPP session are transmitted over the tunnel between the LAC and LNS. L2TP tunneling modes and tunnel establishment process L2TP tunneling modes include NAS-initiated, client-initiated, and LAC-auto-initiated. NAS-initiated tunneling mode As shown in Figure 79, a remote system dials in to the LAC through a PPPoE/ISDN network. The LAC initiates a tunneling request to the LNS over the Internet. Figure 79 NAS-initiated tunneling mode A NAS-initiated tunnel has the following characteristics: 242

259 The remote system only needs to support PPP, and it does not need to support L2TP. Authentication and accounting of the remote system can be implemented on the LAC or LNS. Figure 80 NAS-initiated tunnel establishment process Remote system Host A LAC Device A RADIUS server A LNS Device B RADIUS server B (1) Call setup (2) LCP negotiation (3) PAP or CHAP authenticaion (4) Access request (5) Access accept (6) Tunnel setup request (7) CHAP authentication (challenge/response) (8) Setup a session (9) Send user information and LCP negotiation parameters (10) Access request (11) Acesss accept (12) Assign an IP address (13) Access the enterprise network As shown in Figure 80, the following workflow is used to establish a NAS-initiated tunnel: 1. A remote system (Host A) initiates a PPP connection to the LAC (Device A). 2. The remote system and LAC perform PPP LCP negotiation. 3. The LAC authenticates PPP user information of Host A by using PAP or CHAP. 4. The LAC sends the authentication information (username and password) to its RADIUS server (RADIUS server A) for authentication. 5. RADIUS server A authenticates the user and returns the result. 6. The LAC initiates an L2TP tunneling request to the LNS (Device B) when the following conditions exist: The user passes the authentication. The user is determined to be an L2TP user according to the username or the ISP domain to which the user belongs. 7. If tunnel authentication is needed, the LAC and LNS send CHAP challenge messages to authenticate each other before successfully establishing an L2TP tunnel. 8. The LAC and LNS negotiate to establish L2TP sessions. 9. The LAC sends PPP user information and PPP negotiation parameters to the LNS. 10. The LNS sends the authentication information to its RADIUS server (RADIUS server B) for authentication. 11. RADIUS server B authenticates the user and returns the result. 12. If the user passes the authentication, the LNS assigns a private IP address to the remote system (Host A). 13. The PPP user can access internal resources of the enterprise. 243

260 In steps 12 and 13, the LAC forwards packets for the remote system and LNS. Host A and LAC exchange PPP frames, and the LAC and LNS exchange L2TP packets. Client-initiated tunneling mode As shown in Figure 81, a remote system running L2TP (LAC client) has a public IP address to communicate with the LNS through the Internet. The LAC client can directly initiate a tunneling request to the LNS without any dedicated LAC devices. Figure 81 Client-initiated tunneling mode A client-initiated tunnel has the following characteristics: A client-initiated tunnel has higher security because it is established between a remote system and the LNS. The remote system must support L2TP and be able to communicate with the LNS. This causes poor expandability. As shown in Figure 82, the workflow for establishing a client-initiated tunnel is similar to that for establishing a NAS-initiated tunnel. (Details not shown.) Figure 82 Client-initiated tunnel establishment process LAC-auto-initiated tunneling mode In NAS-initiated mode, a remote system must successfully dial in to the LAC through PPPoE or ISDN. In LAC-auto-initiated mode, you can use the l2tp-auto-client command on the LAC to trigger the LAC to initiate a tunneling request to the LNS. When a remote system accesses the private network, the LAC forwards data through the L2TP tunnel. 244

261 Figure 83 LAC-auto-initiated tunneling mode LAC auto initiated L2TP tunnel Remote system Host A LAN LAC Device A Internet LNS Device B Private network RADIUS server An LAC-auto-initiated tunnel has the following characteristics: The connection between a remote system and the LAC is not confined to a dial-up connection and can be any IP-based connection. An L2TP session is established immediately after an L2TP tunnel is established. Then, the LAC and LNS, acting as the PPPoE client and PPPoE server, respectively, perform PPP negotiation. An L2TP tunnel can carry only one L2TP session. The LNS assigns a private IP address to the LAC instead of to the remote system. As shown in Figure 84, the workflow for establishing an LAC-auto-initiated tunnel is similar to that for establishing a NAS-initiated tunnel. (Details not shown.) Figure 84 Establishment process for LAC-auto-initiated tunnels L2TP features Flexible identity authentication mechanism and high security L2TP by itself does not provide security for connections. However, it has all the security features of PPP and allows for PPP authentication (CHAP or PAP). L2TP can also cooperate with IPsec to improve security for tunneled data. Multiprotocol transmission L2TP tunnels PPP frames, which can be used to encapsulate packets of multiple network layer protocols. RADIUS authentication An LAC or LNS can send the username and password of a remote user to a RADIUS server for authentication. 245

262 Private address allocation An LNS can dynamically allocate private addresses to remote users. This facilitates address allocation for private internets (RFC 1918) and improves security. Flexible accounting Accounting can be simultaneously performed on the LAC and LNS. This allows bills to be generated on the ISP side and charging and auditing to be processed on the enterprise gateway. L2TP can provide accounting data, including inbound and outbound traffic statistics (in packets and bytes) and the connection's start time and end time. The AAA server uses these data for flexible accounting. Reliability L2TP supports LNS backup. When the connection to the primary LNS is torn down, an LAC can establish a new connection to a secondary LNS. This redundancy enhances the reliability of L2TP services. Issuing tunnel attributes by RADIUS server to LAC In NAS-initiated mode, the tunnel attributes can be issued by the RADIUS server to the LAC. For the LAC to receive these attributes, enable L2TP and configure remote AAA authentication for PPP users on the LAC. When an L2TP user dials in to the LAC, the LAC as the RADIUS client sends the user information to the RADIUS server. The RADIUS server authenticates the PPP user, returns the result to the LAC, and issues L2TP tunnel attributes for the PPP user to the LAC. The LAC then sets up an L2TP tunnel and sessions based on the issued L2TP tunnel attributes. Table 12 Tunnel attributes that can be issued by the RADIUS server Attribute number Attribute name Description 64 Tunnel-Type Tunnel type, which can only be L2TP. 65 Tunnel-Medium-Type Transmission medium type for the tunnel, which can only be IPv4. 67 Tunnel-Server-Endpoint IP address of the LNS. 69 Tunnel-Password Key used to authenticate a peer of the tunnel. 81 Tunnel-Private-Group-I D Group ID for the tunnel. The LAC sends this value to the LNS for the LNS to perform an operation accordingly. 82 Tunnel-Assignment-ID 90 Tunnel-Client-Auth-ID Assignment ID for the tunnel. It is used to indicate the tunnel to which a session is assigned. L2TP users with the same Tunnel-Assignment-ID, Tunnel-Server-Endpoint, and Tunnel-Password attributes share an L2TP tunnel. Tunnel name. It is used to indicate the local tunnel. The RADIUS server can issue only one set of the L2TP tunnel attributes in a RADIUS packet. The RADIUS-issued tunnel attributes override the tunnel attributes manually configured on the LAC, but not vice versa. L2TP tunnel switching Also called multihop L2TP tunneling. As shown in Figure 85, the Layer 2 tunnel switch (LTS) terminates L2TP packets from each LAC as an LNS. It then sends these packets to a destination LNS as an LAC. L2TP tunnel switching has the following features: Simplified configuration and deployment When LACs and LNSs are in different management domains: All LACs consider the LTS as an LNS and do not need to differentiate LNSs on the network. All LNSs consider the LTS as an LAC and are not affected by the addition or deletion of LACs. 246

263 L2TP tunnel sharing Different users can share the same L2TP tunnel between the LAC and the LTS. The LTS distributes data of different users to different LNSs. Figure 85 L2TP tunnel switching network diagram L2TP-based EAD EAD authenticates PPP users that pass the access authentication. PPP users that pass EAD authentication can access network resources. PPP users that fail EAD authentication can only access the resources in the quarantine areas. EAD uses the following procedure: 1. The inode client uses L2TP to access the LNS. After the client passes the PPP authentication, the CAMS/IMC server assigns isolation ACLs to the LNS. The LNS uses the isolation ACLs to filter incoming packets. 2. After the IPCP negotiation, the LNS sends the IP address of the CAMS/IMC server to the inode client. The server IP address is permitted by the isolation ACLs. 3. The CAMS/IMC server authenticates the inode client and performs security check for the inode client. If the inode client passes security check, the CAMS/IMC server assigns security ACLs for the inode client to the LNS. The inode client can access network resources. Protocols and standards RFC 1661, The Point-to-Point Protocol (PPP) RFC 1918, Address Allocation for Private Internets RFC 2661, Layer Two Tunneling Protocol "L2TP" RFC 2868, RADIUS Attributes for Tunnel Protocol Support Restrictions: Hardware compatibility with L2TP Only CSPEX cards support L2TP. Restrictions and guidelines: L2TP configuration Make sure the statistics polling interval is 300 seconds when you configure L2TP. For more information about the statistics polling interval, see Ethernet interface configuration in Interface Configuration Guide. 247

264 L2TP tasks at a glance When you configure L2TP, perform the following tasks: 1. Determine the network devices needed according to the networking environment. For NAS-initiated mode and LAC-auto-initiated mode, configure both the LAC and the LNS. For client-initiated mode, you only need to configure the LNS. 2. Configure the devices based on the intended role (LAC or LNS) on the network. To configure a device as an LAC in NAS-initiated or LAC-auto-initiated mode, complete the following tasks: Tasks at a glance (Required.) Configuring basic L2TP capabilities Configuring an LAC: (Required.) Configuring an LAC to initiate tunneling requests for a user (Required.) Specifying LNS IP addresses (Optional) Configuring the source IP address of L2TP tunnel packets (Optional) Configuring each L2TP user to use an L2TP tunnel exclusively (Optional.) Enabling transferring AVP data in hidden mode (Required.) Configuring AAA authentication on an LAC (Required.) Configuring an LAC to automatically establish an L2TP tunnel (Optional.) Configuring optional L2TP parameters: Configuring L2TP tunnel authentication Setting the Hello interval Setting the DSCP value of L2TP packets Setting the TSA ID of the LTS Remarks N/A The first and fifth tasks are required for NAS-initiated mode and unnecessary for LAC-auto-initiated mode. The last task is required for LAC-auto-initiated mode and unnecessary for NAS-initiated mode. N/A To configure a device as an LNS in NAS-initiated, client-initiated, or LAC-auto-initiated mode, complete the following tasks: Tasks at a glance (Required.) Configuring basic L2TP capabilities Configuring an LNS: (Required.) Creating a VT interface (Required.) Configuring an LNS to accept L2TP tunneling requests from an LAC (Optional.) Configuring user authentication on an LNS (Optional.) Configuring AAA authentication on an LNS (Optional.) Setting the maximum number of ICRQ packets that the LNS can process per second (Optional.) Configuring optional L2TP parameters: Configuring L2TP tunnel authentication Setting the Hello interval Setting the DSCP value of L2TP packets Setting the TSA ID of the LTS (Optional.) Enabling L2TP-based EAD (Optional.) Configuring IMSI/SN binding authentication on the LNS 248

265 Configuring basic L2TP capabilities Basic L2TP capability configuration includes the following tasks: Enabling L2TP L2TP must be enabled for L2TP configurations to take effect. Creating an L2TP group An L2TP group is intended to represent a group of parameters. This enables not only flexible L2TP configuration on devices, but also one-to-one and one-to-many networking applications for LACs and LNSs. An L2TP group has local significance only. However, the relevant settings of the L2TP groups on the LAC and LNS must match. For example, the local tunnel name configured on the LAC must match the tunnel peer name configured on the LNS. Configuring the local tunnel name The local tunnel name identifies the tunnel at the local end during tunnel negotiation between an LAC and an LNS. To configure basic L2TP capabilities: 2. Enable L2TP. l2tp enable By default, L2TP is disabled. 3. Create an L2TP group, specify its mode, and enter its view. 4. Specify the local tunnel name. l2tp-group group-number mode { lac lns } tunnel name name By default, no L2TP group exists. Specify the mode as lac on the LAC side and as lns on the LNS side. Optional. By default, the device name is used. Configuring an LAC An LAC establishes tunnels with LNSs and forwards packets between LNSs and remote systems. Configuring an LAC to initiate tunneling requests for a user This task configures an LAC to initiate tunneling requests to an LNS for a user. When the PPP user information matches the specified user, the LAC determines that the PPP user is an L2TP user and initiates tunneling requests to the LNS. You can specify a user by configuring one of the following items: Fully qualified name The LAC initiates tunneling requests to the LNS only if the username of a PPP user matches the configured fully qualified name. Domain name The LAC initiates tunneling requests to the LNS only if the ISP domain name of a PPP user matches the configured domain name. To configure an LAC to initiate tunneling requests for a user: 2. Enter L2TP group view in LAC mode. l2tp-group group-number [ mode lac ] N/A 249

266 3. Configure the LAC to initiate tunneling requests for a user. user { domain domain-name fullusername user-name } By default, an LAC does not initiate tunneling requests for any users. Specifying LNS IP addresses You can specify up to five LNS IP addresses. The LAC initiates an L2TP tunneling request to its specified LNSs consecutively in their configuration order until it receives an acknowledgment from an LNS. That LNS then becomes the tunnel peer. To specify LNS IP addresses: 2. Enter L2TP group view in LAC mode. l2tp-group group-number [ mode lac ] N/A 3. Specify LNS IP addresses. lns-ip { ip-address }&<1-5> By default, no LNS IP addresses are specified. Configuring the source IP address of L2TP tunnel packets For high availability, as a best practice, use the IP address of a loopback interface as the source IP address of L2TP tunnel packets on the LAC. If equal cost routing paths exist between the LAC and LNS, you must use the IP address of a loopback interface as the source IP address of L2TP tunnel packets. To do so, use the source-ip command or use the RADIUS server to assign a loopback interface address. To configure the source IP address of L2TP tunnel packets: 2. Enter L2TP group view in LAC mode. 3. Configure the source IP address of L2TP tunnel packets. l2tp-group group-number [ mode lac ] source-ip ip-address N/A By default, the source IP address of L2TP tunnel packets is the IP address of the egress interface. Configuring each L2TP user to use an L2TP tunnel exclusively By default, an L2TP tunnel can be used by multiple L2TP users. After this feature is configured for a L2TP group, each L2TP user in the group uses an L2TP tunnel exclusively. Only LACs support this feature. To configure each L2TP user to use an L2TP tunnel exclusively: 250

267 2. Enter L2TP group view in LAC mode. 3. Configure each L2TP user to use an L2TP tunnel exclusively. l2tp-group group-number [ mode lac ] tunnel-per-user N/A By default, an L2TP tunnel can be used by multiple L2TP users. Enabling transferring AVP data in hidden mode L2TP uses Attribute Value Pairs (AVPs) to transmit tunnel negotiation parameters, session negotiation parameters, and user authentication information. Transferring AVP data in hidden mode can hide sensitive AVP data such as user passwords. This feature encrypts AVP data with the key configured by using the tunnel password command before transmission. This configuration takes effect only when the tunnel authentication feature is enabled. For more information about configuring tunnel authentication, see "Configuring L2TP tunnel authentication." To enable transferring AVP data in hidden mode: 2. Enter L2TP group view in LAC mode. 3. Enable transferring AVP data in hidden mode. l2tp-group group-number [ mode lac ] tunnel avp-hidden N/A By default, AVP data is transferred in plain text. Configuring AAA authentication on an LAC You can configure AAA authentication an LAC to authenticate the remote dialup users and initiate a tunneling request only for qualified users. A tunnel will not be established for unqualified users. The device supports both local AAA authentication and remote AAA authentication. For local AAA authentication, create a local user and configure a password for each remote user on the LAC. The LAC then authenticates a remote user by matching the provided username and password with those configured locally. For remote AAA authentication, configure the username and password of each user on the RADIUS/HWTACACS server. The LAC then sends the remote user's username and password to the server for authentication. For more information, see "Configuring AAA." To enable AAA authentication on an LAC, you also need to configure PAP or CHAP authentication for PPP users on the user access interfaces. For more information, see PPP configuration in User Access Configuration Guide. Configuring an LAC to automatically establish an L2TP tunnel To configure an LAC to automatically establish an L2TP tunnel, perform the following tasks: Create a virtual PPP interface and configure an IP address for the interface. In virtual PPP interface view, use the ppp pap or ppp chap command to configure the side to be authenticated by PPP as follows: 251

268 Specify the PPP authentication method for the PPP user. Configure the username and password of the PPP user. The LNS then authenticates the PPP user. For more information, see PPP configuration in User Access Configuration Guide. Trigger the LAC to automatically establish an L2TP tunnel. To configure an LAC to automatically establish an L2TP tunnel: 2. Create a virtual PPP interface and enter its view. 3. Configure the IP address of the virtual PPP interface. 4. Configure the peer to be authenticated. 5. Configure the LAC to automatically establish an L2TP tunnel with the LNS. interface virtual-ppp interface-number Assign an IP address to the virtual PPP interface. ip address address mask Enable IP address negotiation on the virtual PPP interface. ip address ppp-negotiate For more information, see PPP configuration in User Access Configuration Guide. l2tp-auto-client l2tp-group group-number By default, no virtual PPP interface exists. By default, no IP address is configured. N/A By default, an LAC does not establish an L2TP tunnel. An L2TP tunnel automatically established in LAC-auto-initiated mode exists until you remove the tunnel by using the undo l2tp-auto-client or undo l2tp-group group-number command. 6. (Optional.) Set the description for the interface. 7. Set the MTU size of the interface. 8. (Optional.) Set the keepalive interval. 9. (Optional.) Set the keepalive retry limit. description text mtu size timer-hold seconds By default, the description of an interface is in the format of interface-name Interface, for example, Virtual-PPP254 Interface. The default setting is 1500 bytes. The default setting is 10 seconds. timer-hold retry retries The default setting is (Optional.) Set the expected bandwidth for the interface. 11. (Optional.) Restore the default settings for the interface. 12. (Optional.) Bring up the interface. bandwidth bandwidth-value default undo shutdown By default, the expected bandwidth (in kbps) is interface baudrate divided by N/A By default, an interface is up. 252

269 Configuring an LNS An LNS responds to the tunneling requests from an LAC, authenticates users, and assigns IP addresses to users. Creating a VT interface After an L2TP session is established, a PPP session is needed for data exchange with the peer. The system will dynamically create PPP sessions based on the parameters of the virtual template (VT) interface. To configure an LNS, first create a VT interface and configure the following parameters for it: Interface IP address. Authentication mode for PPP users. IP addresses allocated by the LNS to PPP users. For more information, see User Access Configuration Guide and Layer 3 IP Services Configuration Guide. Configuring an LNS to accept L2TP tunneling requests from an LAC When receiving a tunneling request, an LNS performs the following operations: Determines whether to accept the tunneling request by checking whether the name of the tunnel peer (LAC) matches the one configured. Determines the VT interface to be used for creating the PPP session. To configure an LNS to accept L2TP tunneling requests from an LAC: 2. Enter L2TP group view in LNS mode. 3. Configure the LNS to accept tunneling requests from an LAC and specify the VT interface to be used for tunnel setup. l2tp-group group-number [ mode lns ] If the L2TP group number is 1: allow l2tp virtual-template virtual-template-number [ remote remote-name ] If the L2TP group number is not 1: allow l2tp virtual-template virtual-template-number remote remote-name N/A By default, an LNS denies tunneling requests from any LAC. If the L2TP group number is 1, the remote remote-name option is optional. If you do not specify this option, the LNS accepts tunneling requests from any LAC. Configuring user authentication on an LNS An LNS can be configured to authenticate a user that has passed authentication on the LAC to increase security. In this case, the user is authenticated once on the LAC and once on the LNS. An L2TP tunnel can be established only when both authentications succeed. An LNS provides the following authentication methods in ascending order of priority: 253

270 Proxy authentication The LNS uses the LAC as an authentication proxy. The LAC sends the LNS all user authentication information from users and the authentication method configured on the LAC itself. The LNS then checks the user validity according to the received information and the locally configured authentication method. Mandatory CHAP authentication The LNS uses CHAP authentication to reauthenticate users who have passed authentication on the LAC. LCP renegotiation The LNS ignores the LAC proxy authentication information and performs a new round of LCP negotiation with the user. The LNS chooses an authentication method depending on your configuration. If you configure both LCP renegotiation and mandatory CHAP authentication, the LNS uses LCP renegotiation. If you configure only mandatory CHAP authentication, the LNS performs CHAP authentication for users after proxy authentication succeeds. If you configure neither LCP renegotiation nor mandatory CHAP authentication, the LNS uses the LAC for proxy authentication. Configuring mandatory CHAP authentication When mandatory CHAP authentication is configured, a user who uses an LAC to initiate tunneling requests is authenticated by both the LAC and the LNS. Some users might not support the authentication on the LNS. In this situation, do not enable this feature, because CHAP authentication on the LNS will fail. For this feature to take effect, you must also configure CHAP authentication for the PPP user on the VT interface of the LNS. To configure mandatory CHAP authentication: 2. Enter L2TP group view in LNS mode. 3. Configure mandatory CHAP authentication. l2tp-group group-number [ mode lns ] mandatory-chap N/A By default, CHAP authentication is not performed on an LNS. This command is effective only on NAS-initiated L2TP tunnels. Configuring LCP renegotiation To establish a NAS-initiated L2TP tunnel, a user first negotiates with the LAC at the start of a PPP session. If the negotiation succeeds, the LAC initiates an L2TP tunneling request and sends user information to the LNS. The LNS then authenticates the user according to the proxy authentication information received. For the LNS not to accept LCP negotiation parameters, configure this feature to perform a new round of LCP negotiation between the LNS and the user. In this case, the LNS authenticates the user by using the authentication method configured on the corresponding VT interface. If you enable LCP renegotiation but configure no authentication for the corresponding VT interface, the LNS does not perform an additional authentication for users. To configure the LNS to perform LCP renegotiation with users: 254

271 2. Enter L2TP group view in LNS mode. l2tp-group group-number [ mode lns ] N/A 3. Configure the LNS to perform LCP renegotiation with users. mandatory-lcp By default, an LNS does not perform LCP renegotiation with users. This command is effective only on NAS-initiated L2TP tunnels. Configuring AAA authentication on an LNS After you configure AAA authentication on an LNS, the LNS can authenticate the usernames and passwords of remote access users. If a user passes AAA authentication, the user can communicate with the LNS to access the private network. Configure AAA authentication on the LNS in one of the following cases: LCP renegotiation is not configured in NAS-initiated mode. The VT interface is configured with PPP user authentication and LCP renegotiation is configured in NAS-initiated mode. The VT interface is configured with PPP user authentication in client-initiated mode or LAC-auto-initiated mode. LNS side AAA configurations are similar to those on an LAC (see "Configuring AAA authentication on an LAC"). Setting the maximum number of ICRQ packets that the LNS can process per second To avoid device performance degradation and make sure the LNS can processes ICRQ requests correctly, use this feature to adjust the ICRQ packet processing rate limit. To set the maximum number of ICRQ packets that the LNS can process per second: 2. Set the maximum number of ICRQ packets that the LNS can process per second l2tp icrq-limit number By default, the maximum number of ICRQ packets that the LNS can process per second is not limited. Configuring optional L2TP parameters The optional L2TP parameter configuration tasks apply to both LACs and LNSs. Configuring L2TP tunnel authentication Tunnel authentication allows the LAC and LNS to authenticate each other. Either the LAC or the LNS can initiate a tunnel authentication request. You can enable tunnel authentication on both sides or either side. 255

272 To ensure a successful tunnel establishment when tunnel authentication is enabled on both sides or either side, set the same non-null key on the LAC and the LNS. To set the tunnel authentication key, use the tunnel password command. When neither side is enabled with tunnel authentication, the key settings of the LAC and the LNS do not affect the tunnel establishment. To ensure tunnel security, enable tunnel authentication. For the tunnel authentication key change to take effect, change the tunnel authentication key before tunnel negotiation is performed. To configure L2TP tunnel authentication: 2. Enter L2TP group view. 3. Enable L2TP tunnel authentication. 4. Set the tunnel authentication key. l2tp-group group-number [ mode { lac lns } ] tunnel authentication tunnel password { cipher simple } string N/A By default, L2TP tunnel authentication is enabled. By default, no key is set. Setting the Hello interval To check the connectivity of a tunnel, the LAC and LNS periodically send each other Hello packets. At receipt of a Hello packet, the LAC or LNS returns a response packet. If the LAC or LNS receives no response packets from the peer within the Hello interval, it retransmits the Hello packet. If it receives no response packets from the peer after transmitting the Hello packet eight times, it considers the L2TP tunnel to be down. To set the Hello interval: 2. Enter L2TP group view. l2tp-group group-number [ mode { lac lns } ] N/A 3. Set the Hello interval. tunnel timer hello hello-interval The default setting is 60 seconds. Setting the DSCP value of L2TP packets The DSCP field is the first 6 bits of the IP ToS byte. This field marks the priority of IP packets for forwarding. This feature sets the DSCP value for the IP packet when L2TP encapsulates a PPP frame into an IP packet. To set the DSCP value of L2TP packets: 2. Enter L2TP group view. 3. Set the DSCP value of L2TP packets. l2tp-group group-number [ mode { lac lns } ] N/A ip dscp dscp-value The default setting is

273 Setting the TSA ID of the LTS To detect loops, the LTS compares the configured TSA ID with each TSA ID AVP in a received ICRQ packet. If a match is found, a loop exists. The LTS immediately tears down the session. If no match is found, the LTS performs the following operations: Encapsulates the configured TSA ID into a new TSA ID AVP. Appends it to the packet. Sends the packet to the next hop LTS. To avoid loop detection errors, make sure the TSA ID of each LTS is unique. To set the TSA ID of the LTS: 2. Set the TSA ID of the LTS and enable L2TP loop detection on the LTS. l2tp tsa-id tsa-id By default, the TSA ID of the LTS is not configured, and L2TP loop detection is disabled on the LTS. Enabling L2TP-based EAD Restrictions and guidelines EAD authentication fails if no or incorrect ACLs or rules are configured on the CAMS/IMC server even if EAD is enabled on the LNS. The LNS can use different ACLs to filter packets from different inode clients. As a best practice, use EAD authentication for inode clients on the Internet and use portal authentication for inode clients on a LAN. Prerequisites Make sure AAA, RADIUS, L2TP, firewalls, and PPP are configured as required before you enable L2TP-based EAD. For more information about portal, see "Configuring portal authentication." For more information about AAA and RADIUS, see "Configuring AAA." For more information about configuring the security policy server, see CAMS EAD Security Policy Manager Help and CAMS EAD Security Policy Manager Help. Procedure To enable L2TP-based EAD: 2. Create a VT interface and enter its view interface virtual-template interface-number N/A 3. Enable L2TP-based EAD. ppp access-control enable By default, L2TP-based EAD is disabled. 257

274 Configuring IMSI/SN binding authentication on the LNS Configure this feature on the LNS to initiate IMSI/SN binding authentication in either of the following conditions: A 3G or 4G router acts as a LAC client and accesses the LNS in client-initiated mode. A 4G router acts as an LAC and is automatically triggered to access the LNS in LAC-auto-initiated mode. To configure IMSI/SN binding authentication on the LNS: 2. Create a VT interface and enter its view 3. Enable the LNS to initiate IMSI/SN binding authentication requests. 4. (Optional.) Replace the client username with the IMSI or SN information for authentication. interface virtual-template interface-number Enable the LNS to initiate IMSI/SN binding authentication requests: ppp lcp imsi request ppp lcp sn request Configure the separator for the received authentication information: ppp user accept-format imsi-sn split splitchart ppp user replace { imsi sn } N/A By default, the LNS does not initiate IMSI/SN binding authentication requests, and no separator is configured for the received authentication information. By default, the client username is used for authentication. Display and maintenance commands for L2TP Execute display commands in any view and reset commands in user view. Task Command Display L2TP tunnel information. display l2tp tunnel [ statistics ] Display L2TP session information. display l2tp session [ statistics ] Display access control information for PPP sessions on a VT interface. Display information about temporary L2TP sessions. Display information about virtual PPP interfaces. display ppp access-control interface virtual-template interface-number display l2tp session temporary display interface [ virtual-ppp [ interface-number ] ] [ brief [ description down ] ] Disconnect an L2TP tunnel. reset l2tp tunnel { id tunnel-id name remote-name } Clear the statistics for virtual PPP interfaces. reset counters interface [ virtual-ppp [ interface-number ] ] 258

275 L2TP configuration examples Example: Configuring a NAS-initiated L2TP tunnel Network configuration As shown in Figure 86, a PPP user is connected to an LNS through an LAC. Set up an L2TP tunnel between the LAC and LNS to allow the PPP user to access the corporate network. Figure 86 Network diagram Procedure 1. Configure the LAC: # Configure IP addresses for the interfaces. (Details not shown.) # Create a local user named vpdnuser, set the password, and enable the PPP service. <LAC> system-view [LAC] local-user vpdnuser class network [LAC-luser-network-vpdnuser] password simple Hello [LAC-luser-network-vpdnuser] service-type ppp [LAC-luser-network-vpdnuser] quit # Configure local authentication for PPP users in ISP domain system. [LAC] domain system [LAC-isp-system] authentication ppp local [LAC-isp-system] quit # Configure Virtual-Template 1 to use CHAP for authentication. [LAC] interface virtual-template 1 [LAC-Virtual-Template1] ppp authentication-mode chap domain system [LAC-Virtual-Template1] quit # Enable the PPPoE server on GigabitEthernet 3/1/1, and bind the interface to Virtual-Template 1. [LAC] interface gigabitethernet 3/1/1 [LAC-GigabitEthernet3/1/1] pppoe-server bind virtual-template 1 [LAC-GigabitEthernet3/1/1] quit # Enable L2TP. [LAC] l2tp enable # Create L2TP group 1 in LAC mode. [LAC] l2tp-group 1 mode lac # Configure the local tunnel name as LAC. [LAC-l2tp1] tunnel name LAC # Specify PPP user vpdnuser as the condition for the LAC to initiate tunneling requests. [LAC-l2tp1] user fullusername vpdnuser # Specify the LNS IP address as

276 [LAC-l2tp1] lns-ip # Enable tunnel authentication, and specify the tunnel authentication key as aabbcc. [LAC-l2tp1] tunnel authentication [LAC-l2tp1] tunnel password simple aabbcc [LAC-l2tp1] quit 2. Configure the LNS: # Configure IP addresses for the interfaces. (Details not shown.) # Create a local user named vpdnuser, set the password, and enable the PPP service. <LNS> system-view [LNS] local-user vpdnuser class network [LNS-luser-network-vpdnuser] password simple Hello [LNS-luser-network-vpdnuser] service-type ppp [LNS-luser-network-vpdnuser] quit # Configure local authentication for PPP users in ISP domain system. [LNS] domain system [LNS-isp-system] authentication ppp local [LNS-isp-system] quit # Enable L2TP. [LNS] l2tp enable # Create a PPP address pool. [LNS] ip pool aaa [LNS] ip pool aaa gateway # Create Virtual-Template 1, specify its PPP authentication mode as CHAP, and use address pool aaa to assign IP addresses to the PPP users. [LNS] interface virtual-template 1 [LNS-virtual-template1] ppp authentication-mode chap domain system [LNS-virtual-template1] remote address pool aaa [LNS-virtual-template1] quit # Create L2TP group 1 in LNS mode. [LNS] l2tp-group 1 mode lns # Configure the local tunnel name as LNS. [LNS-l2tp1] tunnel name LNS # Specify Virtual-Template 1 for receiving calls from an LAC. [LNS-l2tp1] allow l2tp virtual-template 1 remote LAC # Enable tunnel authentication, and specify the tunnel authentication key as aabbcc. [LNS-l2tp1] tunnel authentication [LNS-l2tp1] tunnel password simple aabbcc [LNS-l2tp1] quit 3. On the remote system, enter vpdnuser as the username and Hello as the password in the dial-up network window to dial a connection. Verifying the configuration # After the dial-up connection is established, use the display ppp access-user command on the LNS to display the online user information. [LNS] display ppp access-user user-type lns Interface Username MAC address IP address IPv6 address IPv6 PDPrefix BAS0 vpdnuser

277 # After the dial-up connection is established, verify that the remote system can obtain an IP address and can ping the private IP address of the LNS. # On the LNS, use the display l2tp tunnel command to check the established L2TP tunnels. [LNS] display l2tp tunnel LocalTID RemoteTID State Sessions RemoteAddress RemotePort RemoteName Established LAC # On the LNS, use the display l2tp session command to check the established L2TP sessions. [LNS] display l2tp session LocalSID RemoteSID LocalTID State Established Example: Configuring a client-initiated L2TP tunnel Network configuration As shown in Figure 87, a PPP user directly initiates a tunneling request to the LNS to access the corporate network. Figure 87 Network diagram Procedure 1. Configure the LNS: # Configure IP addresses for the interfaces. (Details not shown.) # Configure the route between the LNS and the remote host. (Details not shown.) # Create a local user named vpdnuser, set the password, and enable the PPP service. [LNS] local-user vpdnuser class network [LNS-luser-network-vpdnuser] password simple Hello [LNS-luser-network-vpdnuser] service-type ppp [LNS-luser-network-vpdnuser] quit # Configure local authentication for PPP users in ISP domain system. [LNS] domain system [LNS-isp-system] authentication ppp local [LNS-isp-system] quit # Enable L2TP. [LNS] l2tp enable # Create a PPP address pool. [LNS] ip pool aaa [LNS] ip pool aaa gateway # Create Virtual-Template 1, specify its PPP authentication mode as CHAP, and use address pool aaa to assign IP addresses to the PPP users. [LNS] interface virtual-template 1 [LNS-virtual-template1] ppp authentication-mode chap domain system 261

278 [LNS-virtual-template1] remote address pool aaa [LNS-virtual-template1] quit # Create L2TP group 1 in LNS mode. [LNS] l2tp-group 1 mode lns # Configure the local tunnel name as LNS. [LNS-l2tp1] tunnel name LNS # Specify Virtual-Template 1 for receiving calls. [LNS-l2tp1] allow l2tp virtual-template 1 # Disable tunnel authentication. [LNS-l2tp1] undo tunnel authentication 2. Configure the remote host: # Configure the IP address of the remote host as , and configure a route to the LNS ( ). # Create a virtual private network connection by using the Windows system, or install the L2TP LAC client software, such as WinVPN Client. # Complete the following configuration procedure (the procedure depends on the client software): Specify the PPP username as vpdnuser and the password as Hello. Specify the Internet interface address of the security gateway as the IP address of the LNS. In this example, the Ethernet interface for the tunnel on the LNS has an IP address of Modify the connection attributes: set the protocol to L2TP, the encryption attribute to customized, and the authentication mode to CHAP. Verifying the configuration # On the remote host, initiate the L2TP connection. After the dial-up connection is established, use the display ppp access-user command on the LNS to display the online user information. [LNS] display ppp access-user user-type lns Interface Username MAC address IP address IPv6 address IPv6 PDPrefix BAS0 vpdnuser # On the remote host, initiate the L2TP connection. After the connection is established, verify that the remote host can obtain the IP address and ping the private IP address of the LNS ( ). # On the LNS, use the display l2tp session command to check the established L2TP session. [LNS-l2tp1] display l2tp session LocalSID RemoteSID LocalTID State Established # On the LNS, use the display l2tp tunnel command to check the established L2TP tunnel. [LNS-l2tp1] display l2tp tunnel LocalTID RemoteTID State Sessions RemoteAddress RemotePort RemoteName Established PC Example: Configuring an LAC-auto-initiated L2TP tunnel Network configuration As shown in Figure 88, configure the LAC to establish an L2TP tunnel with the LNS in LAC-auto-initiated mode. When the PPP user initiates a connection, it uses the established tunnel to access the corporate network. 262

279 Figure 88 Network diagram Procedure 1. Configure the LNS: # Configure IP addresses for the interfaces. (Details not shown.) # Create a local user named vpdnuser, set the password, and enable the PPP service. <LNS> system-view [LNS] local-user vpdnuser class network [LNS-luser-network-vpdnuser] password simple Hello [LNS-luser-network-vpdnuser] service-type ppp [LNS-luser-network-vpdnuser] quit # Create a PPP address pool. [LNS] ip pool aaa [LNS] ip pool aaa gateway # Create Virtual-Template 1, specify its PPP authentication mode as PAP, and use address pool aaa to assign IP addresses to the PPP users. [LNS] interface virtual-template 1 [LNS-virtual-template1] ppp authentication-mode pap [LNS-virtual-template1] remote address pool aaa [LNS-virtual-template1] quit # Configure local authentication for PPP users in ISP domain system. [LNS] domain system [LNS-isp-system] authentication ppp local [LNS-isp-system] quit # Enable L2TP, and create L2TP group 1 in LNS mode. [LNS] l2tp enable [LNS] l2tp-group 1 mode lns # Configure the local tunnel name as LNS, and specify Virtual-Template 1 for receiving tunneling requests from an LAC. [LNS-l2tp1] tunnel name LNS [LNS-l2tp1] allow l2tp virtual-template 1 remote LAC # Enable tunnel authentication, and configure the authentication key as aabbcc. [LNS-l2tp1] tunnel authentication [LNS-l2tp1] tunnel password simple aabbcc [LNS-l2tp1] quit # Configure a static route so that packets destined for the PPP user will be forwarded through the L2TP tunnel. [LNS] ip route-static Configure the LAC: # Configure IP addresses for the interfaces. (Details not shown.) # Enable L2TP. <LAC> system-view [LAC] l2tp enable 263

280 # Create L2TP group 1 in LAC mode. [LAC] l2tp-group 1 mode lac # Configure the local tunnel name as LAC, and specify the IP address of the tunnel peer (LNS). [LAC-l2tp1] tunnel name LAC [LAC-l2tp1] lns-ip # Enable tunnel authentication, and configure the authentication key as aabbcc. [LAC-l2tp1] tunnel authentication [LAC-l2tp1] tunnel password simple aabbcc [LAC-l2tp1] quit # Create Virtual-PPP 1. Configure its username and password as vpdnuser and Hello and PPP authentication as PAP. [LAC] interface virtual-ppp 1 [LAC-Virtual-PPP1] ip address ppp-negotiate [LAC-Virtual-PPP1] ppp pap local-user vpdnuser password simple Hello [LAC-Virtual-PPP1] quit # Configure a static route so that packets destined for the corporate network will be forwarded through the L2TP tunnel. [LAC] ip route-static virtual-ppp 1 # Trigger the LAC to establish an L2TP tunnel with the LNS. [LAC] interface virtual-ppp 1 [LAC-Virtual-PPP1] l2tp-auto-client l2tp-group 1 3. On the remote host, configure the LAC as the gateway. Verifying the configuration # On the LNS, use the display l2tp session command to display the established L2TP session. [LNS] display l2tp session LocalSID RemoteSID LocalTID State Established # On the LNS, use the display l2tp tunnel command to display the established L2TP tunnel. [LNS] display l2tp tunnel LocalTID RemoteTID State Sessions RemoteAddress RemotePort RemoteName Established LAC # On the LNS, verify that you can ping , a private network address on the LAC side. This indicates that hosts on /16 and those on /16 can communicate with each other through the L2TP tunnel. [LNS] ping -a Ping ( ): 56 data bytes, press CTRL_C to break 56 bytes from : icmp_seq=0 ttl=128 time=1.000 ms 56 bytes from : icmp_seq=1 ttl=128 time=1.000 ms 56 bytes from : icmp_seq=2 ttl=128 time=1.000 ms 56 bytes from : icmp_seq=3 ttl=128 time=1.000 ms 56 bytes from : icmp_seq=4 ttl=128 time=1.000 ms --- Ping statistics for packet(s) transmitted, 5 packet(s) received, 0.0% packet loss round-trip min/avg/max/std-dev = 1.000/1.000/1.000/0.000 ms 264

281 Troubleshooting L2TP Failure to access the private network Symptom Solution The remote system cannot access the private network. To resolve the problem: 1. Verify the following items to avoid tunnel setup failures: The address of the LNS is configured correctly on the LAC. For more information, see the lns-ip command. The LNS can accept L2TP tunneling requests from the LAC. For more information, see the allow command. Tunnel authentication is enabled on both the LAC and the LNS, and the tunnel authentication keys configured on the two sides match. 2. Verify the following items to avoid PPP negotiation failures: Usernames and passwords are correctly configured on the LAC and LNS. IP address negotiation settings are correct on the remote system and LNS. The authentication type is consistent. For example, the default authentication type for a VPN connection created on Windows 2000 is MS-CHAP. If the peer does not support MS-CHAP, change the authentication type to CHAP on Windows Data transmission failure Symptom Solution Data transmission fails. A connection is established, but data cannot be transmitted. For example, the LAC and LNS cannot ping each other. To resolve the problem: 1. Use the display ip routing-table command on the LAC and LNS to verify that the LAC has a route to the private network behind the LNS, and vice versa. If no route is available, configure a static route or a dynamic routing protocol. 2. Increase the link bandwidth to enhance the link availability. Internet backbone congestion and high packet loss ratio might cause data transmission failures. L2TP data transmission is based on UDP, which does not provide the packet error control feature. If the line is unstable, the LAC and LNS might be unable to ping each other. 3. If the problem persists, contact H3C Support. L2TP user offline Symptom A L2TP user goes offline when sending a large L2TP packet. Solution To resolve the problem: 265

282 1. Configure a large MTU for the tunnel interface and VT interface of the LAC or LNS to avoid fragmentation. L2TP does not support fragmentation. When the packet size exceeds the MTU of the tunnel interface or the VT interface, the following occurs: If an interface on CSPEX-1204 cards is used as the tunnel interface, the hardware discards the packet because of fragmentation failure. If an interface on CSPEX cards (except CSPEX-1204) is used as the tunnel interface, the packet is not fragmented. The default MTU is even you modify the MTU of the tunnel interface or the VT interface. 2. If the problem persists, contact H3C Support. 266

283 Configuring PPPoE About PPPoE Point-to-Point Protocol over Ethernet (PPPoE) extends PPP by transporting PPP frames encapsulated in Ethernet over point-to-point links. PPPoE specifies the methods for establishing PPPoE sessions and encapsulating PPP frames over Ethernet. PPPoE requires a point-to-point relationship between peers instead of a point-to-multipoint relationship as in multi-access environments such as Ethernet. PPPoE provides Internet access for the hosts in an Ethernet through a remote access device and implements access control, authentication, and accounting on a per-host basis. Integrating the low cost of Ethernet and scalability and management functions of PPP, PPPoE gained popularity in various application environments, such as residential access networks. For more information about PPPoE, see RFC PPPoE network structure PPPoE uses the client/server model. The PPPoE client initiates a connection request to the PPPoE server. After session negotiation between them is complete, a session is established between them, and the PPPoE server provides access control, authentication, and accounting to the PPPoE client. PPPoE network structures are classified into router-initiated and host-initiated network structures depending on the starting point of the PPPoE session. Router-initiated network structure As shown in Figure 89, the PPPoE session is established between routers (Router A and Router B). All hosts share one PPPoE session for data transmission without being installed with PPPoE client software. This network structure is typically used by enterprises. Figure 89 Router-initiated network structure Carrier device DSLAM PPPoE server Router B Internet Client device Modem Router A PPPoE client Host A Host B Host C 267

284 Host-initiated network structure As shown in Figure 90, a PPPoE session is established between each host (PPPoE client) and the carrier router (PPPoE server). The service provider assigns an account to each host for billing and control. The host must be installed with PPPoE client software. Figure 90 Host-initiated network structure PPPoE Client Host A PPPoE Client PPPoE Server Router Internet Host B Protocols and standards RFC 2516: A Method for Transmitting PPP Over Ethernet (PPPoE) Restrictions: Hardware compatibility with IPoE PPPoE is only supported by CSPEX cards. The PPPoE server supports the following interfaces: Layer 3 Ethernet interfaces/subinterfaces. Layer 3 aggregate interfaces/subinterfaces. L3VE interfaces/subinterfaces. Restrictions and guidelines: PPPoE configuration The device can only act as a PPPoE server. Make sure the statistics polling interval is 300 seconds when you configure the PPPoE server. For more information about the statistics polling interval, see Ethernet interface configuration in Interface Configuration Guide. Set the keepalive interval on the VT interface to no less than 60 seconds when the following requirements are met: You need to separate the accounting for IPv4 and IPv6 traffic of a PPPoE user. The PPPoE user goes online through a Layer 3 aggregate interface or a Layer 3 aggregate subinterface. For more information about the keepalive interval on a VT interface, see PPP configuration in User Access Configuration Guide. 268

285 Configuring the PPPoE server PPPoE server tasks at a glance Tasks at a glance (Required.) Configuring a PPPoE session (Optional.) Setting the maximum number of PPPoE sessions (Optional.) Limiting the PPPoE access rate (Optional.) Configuring the NAS-Port-ID attribute (Optional.) Enabling PPPoE users to come online despite the PPPoE-NAT444 collaboration failure (Optional.) Setting the maximum number of PADI packets that the device can receive per second (Optional.) Configuring PPPoE user blocking (Optional.) Enabling PPPoE logging Configuring a PPPoE session 2. Create a VT interface and enter VT interface view. 3. Set PPP parameters. interface virtual-template number For more information, see PPP configuration in User Access Configuration Guide. N/A If authentication is needed, use the PPPoE server as the authenticator. 4. Return to system view. quit N/A 5. Enter interface view. 6. Enable the PPPoE server on the interface and bind this interface to the specified VT interface. 7. (Optional.) Configure an access concentrator (AC) name for the PPPoE server. 8. (Optional.) Enable the PPPoE server to support the ppp-max-payload tag and specify a range for the PPP maximum payload. 9. (Optional.) Set a service name for the PPPoE server interface interface-type interface-number pppoe-server bind virtual-template number pppoe-server tag ac-name name pppoe-server tag ppp-max-payload [ minimum minvalue maximum maxvalue ] pppoe-server tag service-name name N/A By default, the PPPoE server is disabled on the interface. By default, the AC name for the PPPoE server is the device name. PPPoE clients can choose a PPPoE server according to the AC name. The PPPoE client on H3C devices do not support this feature. By default, The PPPoE server does not support the ppp-max-payload tag. By default, the PPPoE server does not have a service name. 269

286 10. (Optional.) Set the response delay time for user access. pppoe-server access-delay delay-time 11. Return to system view. quit N/A By default, no response delay time is set. 12. Configure the PPPoE server to perform authentication, authorization, and accounting for PPP users. See "Configuring AAA." N/A Setting the maximum number of PPPoE sessions PPPoE can establish a session when none of the following limits are reached: Limit for a user on an interface. Limit for a VLAN on an interface. Limit on an interface. Limit on a card. New maximum number settings apply only to subsequently established PPPoE sessions. To configure the maximum number of PPPoE sessions: 2. Enter interface view. 3. Set the maximum number of PPPoE sessions on an interface. 4. Set the maximum number of PPPoE sessions for a VLAN on an interface. 5. Set the maximum number of PPPoE sessions for a user on an interface. interface interface-type interface-number pppoe-server session-limit number pppoe-server session-limit per-vlan number pppoe-server session-limit per-mac number The PPPoE server is enabled on the interface. By default, the number of PPPoE sessions on an interface is not limited. By default, the number of PPPoE sessions for a VLAN on an interface is not limited. By default, a user is allowed to create a maximum of one PPPoE session. 6. Return to system view. quit N/A 7. (In standalone mode.) Set the maximum number of PPPoE sessions on the specified card. 8. (In IRF mode.) Set the maximum number of PPPoE sessions on a card of an IRF member device. pppoe-server session-limit slot slot-number total number pppoe-server session-limit chassis chassis-number slot slot-number total number By default, the number of PPPoE sessions on a card is not limited. By default, the number of PPPoE sessions on a card is not limited. Limiting the PPPoE access rate The device can limit the rate at which a user (identified by an MAC address) can create PPPoE sessions on an interface. If the number of PPPoE requests within the monitoring time exceeds the configured threshold, the device discards the excessive requests, and outputs log messages. If the blocking time is set to 0, the device does not block any requests, and it only outputs log messages. 270

287 The device uses a monitoring table and a blocking table to control PPP access rates: Monitoring table Stores a maximum of 8000 monitoring entries. Each entry records the number of PPPoE sessions created by a user within the monitoring time. When the monitoring entries reach the maximum, the system stops monitoring and blocking session requests from new users. The aging time of monitoring entries is determined by the session-request-period argument. When the timer expires, the system starts a new round of monitoring for the user. Blocking table Stores a maximum of 8000 blocking entries. The system creates a blocking entry if the access rate of a user reaches the threshold, and blocks requests from that user. When the blocking entries reach the maximum number, the system stops blocking session requests from new users and it only outputs log messages. The aging time of the blocking entries is determined by the blocking-period argument. When the timer expires, the system starts a new round of monitoring for the user. If the access rate setting is changed, the system removes all monitoring and blocking entries, and uses the new settings to limit PPPoE access rates. To limit the PPPoE access rate: 2. Enter interface view. 3. Set the PPPoE access limit. 4. Display information about blocked users. interface interface-type interface-number pppoe-server throttle per-mac session-requests session-request-period blocking-period In standalone mode: display pppoe-server throttled-mac { slot slot-number interface interface-type interface-number } In IRF mode: display pppoe-server throttled-mac { chassis chassis-number slot slot-number interface interface-type interface-number } The PPPoE server is enabled on the interface. By default, the PPPoE access rate is not limited. Available in any view. Configuring the NAS-Port-ID attribute The PPPoE server on a BAS device uses the RADIUS NAS-Port-ID attribute to send the access line ID received from a DSLAM device to the RADIUS server. The access line ID includes the circuit-id and remote-id. The RADIUS server compares the received NAS-Port-ID attribute with the local line ID information to verify the location of the user. You can configure the content of the NAS-Port-ID attribute that the PPPoE server sends to the RADIUS server. To configure the NAS-Port-ID attribute: 2. Enter interface view. interface interface-type interface-number The PPPoE server is enabled on the interface. 271

288 3. Configure the content of the NAS-Port-ID attribute. 4. Configure the NAS-Port-ID attribute to include the BAS information automatically. 5. Configure the PPPoE server to trust the access line ID in received packets. pppoe-server access-line-id content { all [ separator ] circuit-id remote-id } pppoe-server access-line-id bas-info [ cn-163 ] pppoe-server access-line-id trust By default, the NAS-Port-ID attribute contains only the circuit-id. By default, the NAS-Port-ID attribute does not include the BAS information automatically. By default, the PPPoE server does not trust the access line ID in received packets. 6. Configure the format that is used to parse the circuit-id. 7. Configure the transmission format for the circuit-id. 8. Configure the transmission format for the remote-id. pppoe-server access-line-id circuit-id parse-mode { cn-telecom tr-101 } pppoe-server access-line-id circuit-id trans-format { ascii hex } pppoe-server access-line-id remote-id trans-format { ascii hex } The default mode is TR-101. The default format is a string of characters. The default format is a string of characters. Enabling PPPoE users to come online despite the PPPoE-NAT444 collaboration failure If a card that supports NAT444 collaboration fails, the PPPoE-NAT444 collaboration fails. You can use this command to enable IPv4 PPPoE users to come online despite the collaboration failure. For more information about NAT444, see NAT in Layer 3 IP Services Configuration Guide. Enabling IPv4 PPPoE users to come online despite the PPPoE-NAT444 collaboration failure 2. Create a VT interface and enter VT interface view. 3. Enable IPv4 PPPoE users to come online despite the PPPoE-NAT444 collaboration failure. interface virtual-template number ppp ip nat-fail online N/A By default, IPv4 PPPoE users cannot come online if the PPPoE-NAT444 collaboration fails. Enabling IPv6 PPPoE users to come online despite the PPPoE-NAT444 collaboration failure 2. Create a VT interface and enter VT interface view. 3. Enable IPv6 PPPoE users to come online despite the PPPoE-NAT444 collaboration failure. interface virtual-template number ppp ipv6 nat-fail online N/A By default, IPv6 PPPoE users cannot come online if the PPPoE-NAT444 collaboration fails. 272

289 Setting the maximum number of PADI packets that the device can receive per second When device reboot or version update is performed, the burst of online requests might affect the device performance. To avoid device performance degradation and make sure the device can process PADI packets correctly, use this feature to adjust the PADI packet receiving rate limit. This feature is only supported by CSPEX cards. To set the maximum number of PADI packets that the device can receive per second: 2. Set the maximum number of PADI packets that the device can receive per second. In standalone mode: pppoe-server padi-limit slot slot-number number In IRF mode: pppoe-server padi-limit chassis chassis-number slot slot-number number The default settings vary by MPU model, as shown in Table 13. Table 13 Default settings for the PADI packet receiving rate limit MPU model PADI packet receiving rate limit CSR07SRPUD3 500 Other MPUs 200 Configuring PPPoE user blocking About PPPoE user blocking You can use this feature to prevent multiple PPPoE users from frequently coming online and going offline or prevent protocol packet attacks. After this feature is enabled, users who performs the following operations for the specified number of times within a period will be blocked: Come online. Go offline. Send PPPoE connection requests. Packets from blocked users will be discarded during the blocking period, and will be processed after the blocking period expires. Restrictions and guidelines for PPPoE user blocking configuration If you enable this feature in system view, the feature applies to all PPPoE users. If you enable this feature in interface view, the feature applies to PPPoE users accessing the interface. If you execute this command in both system view and interface view, a user is monitored by blocking conditions in both views. When the user meets the blocking conditions in any view first, the user is blocked by the blocking settings in the view. 273

290 Enabling MAC-based user blocking in system view 2. Enable MAC-based user blocking. pppoe-server connection chasten [ quickoffline ] [ multi-sessions-permac ] requests request-period blocking-period By default, MAC-based user blocking is disabled. Enabling MAC-based user blocking in interface view 2. Enter interface view. 3. Enable MAC-based user blocking. interface interface-type interface-number pppoe-server connection chasten [ quickoffline ] [ multi-sessions-permac ] requests request-period blocking-period The PPPoE server is enabled on the interface. By default, MAC-based user blocking is disabled. Enabling PPPoE logging The PPPoE logging feature enables the device to generate PPPoE logs and send them to the information center. Logs are generated when the following requirements are met: The number of PPPoE sessions reaches the upper limit for an interface, user, VLAN, or the system. New users request to come online. A log entry records the interface-based, MAC-based, VLAN-based, or system-based session limit. For information about the log destination and output rule configuration in the information center, see Network Management and Monitoring Configuration Guide. As a best practice, disable this feature to prevent excessive PPP log output. To enable PPPoE logging: 2. Enable PPPoE logging. pppoe-server log enable By default, PPPoE logging is disabled. Display and maintenance commands for PPPoE Execute display commands in any view and reset commands in user view. Task (In standalone mode.) Display PPPoE chasten statistics. Command display pppoe-server chasten statistics [ mac-address ] [ interface interface-type interface-number slot slot-number ] 274

291 Task (In IRF mode.) Display PPPoE chasten statistics. (In standalone mode.) Display information about blocked PPPoE users. (In IRF mode.) Display information about blocked PPPoE users. (In standalone mode.) Display summary information for PPPoE sessions. (In IRF mode.) Display summary information for PPPoE sessions. (In standalone mode.) Display packet statistics for PPPoE sessions. (In IRF mode.) Display packet statistics for PPPoE sessions. (In standalone mode.) Display information about blocked users. (In IRF mode.) Display information about blocked users. Clear PPPoE sessions. Command display pppoe-server chasten statistics [ mac-address ] [ interface interface-type interface-number chassis chassis-number slot slot-number ] display pppoe-server chasten user [ mac-address [ mac-address ] ] [ interface interface-type interface-number slot slot-number ] display pppoe-server chasten user [ mac-address [ mac-address ] ] [ interface interface-type interface-number chassis chassis-number slot slot-number ] display pppoe-server session summary { slot slot-number interface interface-type interface-number } display pppoe-server session summary { chassis chassis-number slot slot-number interface interface-type interface-number } display pppoe-server session packet { slot slot-number interface interface-type interface-number } display pppoe-server session packet { chassis chassis-number slot slot-number interface interface-type interface-number } display pppoe-server throttled-mac { slot slot-number interface interface-type interface-number } display pppoe-server throttled-mac { chassis chassis-number slot slot-number interface interface-type interface-number } reset pppoe-server { all interface interface-type interface-number virtual-template number } PPPoE configuration examples Example: Configuring the PPPoE server Network configuration As shown in Figure 91, Host A and Host B run PPPoE client dialup software. The PPPoE server on the router performs local authentication and assigns IP addresses to the clients. Figure 91 Network diagram 275

292 Procedure # Create a PPPoE user. <Router> system-view [Router] local-user user1 class network [Router-luser-network-user1] password simple pass1 [Router-luser-network-user1] service-type ppp [Router-luser-network-user1] quit # Configure Virtual-Template 1 to use CHAP for authentication and use a PPP address pool for IP address assignment. Set the DNS server IP address for the peer. [Router] interface virtual-template 1 [Router-Virtual-Template1] ppp authentication-mode chap domain system [Router-Virtual-Template1] ppp chap user user1 [Router-Virtual-Template1] remote address pool 1 [Router-Virtual-Template1] ppp ipcp dns [Router-Virtual-Template1] quit # Configure a PPP address pool that contains nine assignable IP addresses, and configure a gateway address for the PPP address pool. [Router] ip pool [Router] ip pool 1 gateway # Enable the PPPoE server on GigabitEthernet 3/1/1, and bind the interface to Virtual-Template 1. [Router] interface gigabitethernet 3/1/1 [Router-GigabitEthernet3/1/1] pppoe-server bind virtual-template 1 [Router-GigabitEthernet3/1/1] quit # Configure local authentication for the default ISP domain (system). [Router] domain system [Router-isp-system] authentication ppp local [Router-isp-system] quit Verifying the configuration # Verify that Host A and Host B can access the Internet by using the username user1 and password pass1. (Details not shown.) Example: Assigning the PPPoE server IP address through the local DHCP server Network configuration As shown in Figure 92, configure the PPPoE server as a DHCP server to assign an IP address to the host. Figure 92 Network diagram 276

293 Procedure # Configure Virtual-Template 10 to use PAP for authentication and use a DHCP address pool to allocate IP addresses and DNS server IP addresses for users. <Router> system-view [Router] interface virtual-template 10 [Router-Virtual-Template10] ppp authentication-mode pap [Router-Virtual-Template10] remote address pool pool1 [Router-Virtual-Template10] quit # Enable the PPPoE server on GigabitEthernet 3/1/1, and bind the interface to Virtual-Template 10. [Router] interface gigabitethernet 3/1/1 [Router-GigabitEthernet3/1/1] pppoe-server bind virtual-template 10 [Router-GigabitEthernet3/1/1] quit # Enable DHCP. [Router] dhcp enable # Configure DHCP address pool pool1. [Router] dhcp server ip-pool pool1 [Router-dhcp-pool-pool1] network [Router-dhcp-pool-pool1] gateway-list export-route [Router-dhcp-pool-pool1] dns-list # Exclude the IP address from dynamic allocation in DHCP address pool pool1. [Router-dhcp-pool-pool1] forbidden-ip [Router-dhcp-pool-pool1] quit # Create a PPPoE user. [Router] local-user user1 class network [Router-luser-network-user1] password simple pass1 [Router-luser-network-user1] service-type ppp [Router-luser-network-user1] quit Verifying the configuration # Log in to the router by using username user1 and password pass1. # Display information about IP addresses assigned by the DHCP server. [Router] display dhcp server ip-in-use IP address Client identifier/ Lease expiration Type Hardware address e Unlimited Auto(C) 662e d e65-74 The output shows that the router has assigned an IP address to the host. Example: Assigning the PPPoE server IP address through a remote DHCP server Network configuration As shown in Figure 93, configure the PPPoE server as a DHCP relay agent to relay an IP address from the DHCP server to the host. 277

294 Figure 93 Network diagram Procedure 1. Configure Router A as the PPPoE server: # Configure Virtual-Template 10 to use PAP for authentication and use a DHCP address pool to allocate IP addresses and DNS server IP addresses for users. <RouterA> system-view [RouterA] interface virtual-template 10 [RouterA-Virtual-Template10] ppp authentication-mode pap [RouterA-Virtual-Template10] remote address pool pool1 [RouterA-Virtual-Template10] quit # Enable the PPPoE server on GigabitEthernet 3/1/1, and bind the interface to Virtual-Template 10. [RouterA] interface gigabitethernet 3/1/1 [RouterA-GigabitEthernet3/1/1] pppoe-server bind virtual-template 10 [RouterA-GigabitEthernet3/1/1] quit # Enable DHCP. [RouterA] dhcp enable # Enable recording of relay entries on the relay agent. [RouterA] dhcp relay client-information record # Create DHCP relay address pool pool1. [RouterA] dhcp server ip-pool pool1 # Specify a gateway address for the clients in pool1. [RouterA-dhcp-pool-pool1] gateway-list export-route # Specify a DHCP server for pool1. [RouterA-dhcp-pool-pool1] remote-server [RouterA-dhcp-pool-pool1] quit # Specify an IP address for GigabitEthernet 3/1/2. [RouterA] interface gigabitethernet 3/1/2 [RouterA-GigabitEthernet3/1/2] ip address [RouterA-GigabitEthernet3/1/2] quit # Create a PPPoE user. [RouterA] local-user user1 class network [RouterA-luser-network-user1] password simple pass1 [RouterA-luser-network-user1] service-type ppp [RouterA-luser-network-user1] quit 2. Configure Router B as a DHCP server. # Enable DHCP. <RouterB> system-view [RouterB] dhcp enable # Create DHCP address pool pool1, and specify a primary subnet and a gateway address for DHCP clients. [RouterB] dhcp server ip-pool pool1 278

295 [RouterB-dhcp-pool-pool1] network [RouterB-dhcp-pool-pool1] gateway-list [RouterB-dhcp-pool-pool1] dns-list # Exclude the IP address from dynamic allocation in DHCP address pool pool1. [RouterB-dhcp-pool-pool1] forbidden-ip [RouterB-dhcp-pool-pool1] quit # Specify an IP address for GigabitEthernet 3/1/1. [RouterB] interface gigabitethernet 3/1/1 [RouterB-GigabitEthernet3/1/1] ip address [RouterB-GigabitEthernet3/1/1] quit # Configure a static route to the PPPoE server. [RouterB] ip route-static Verifying the configuration # Log in to Router A by using username user1 and password pass1. # Display relay entries on the DHCP relay agent on Router A. [RouterA] display dhcp relay client-information Total number of client-information items: 1 Total number of dynamic items: 1 Total number of temporary items: 0 IP address MAC address Type Interface VPN name e Dynamic BAS0 N/A # Display information about the assigned IP addresses on Router B. [RouterB] display dhcp server ip-in-use IP address Client identifier/ Lease expiration Type Hardware address e Unlimited Auto(C) The output shows that Router B has assigned an IP address to the host. Example: Assigning the PPPoE server IPv6 address through ND and IPv6CP negotiation Network configuration As shown in Figure 94, configure the PPPoE server to advertise the following information to the host: IPv6 prefix in RA messages. IPv6 interface identifier during IPv6CP negotiation. The host uses the IPv6 prefix and IPv6 interface identifier to generate an IPv6 global unicast address. Figure 94 Network diagram 279

296 Procedure # Create Virtual-Template 10. <Router> system-view [Router] interface virtual-template 10 # Configure Virtual-Template 10 to use PAP to authenticate the peer. [Router-Virtual-Template10] ppp authentication-mode pap domain system # Configure Virtual-Template 10 to automatically generate an IPv6 link-local address. [Router-Virtual-Template10] ipv6 address auto link-local # Enable Virtual-Template 10 to advertise RA messages. [Router-Virtual-Template10] undo ipv6 nd ra halt # Set the other stateful configuration flag (O) to 1 in RA advertisements to be sent. [Router-Virtual-Template10] ipv6 nd autoconfig other-flag # Enable the DHCPv6 Server on Virtual-Template 10. [Router-Virtual-Template10] ipv6 dhcp select server [Router-Virtual-Template10] quit # Enable the PPPoE sever on GigabitEthernet 3/1/1, and bind the interface to Virtual-Template 10. [Router] interface gigabitethernet 3/1/1 [Router-GigabitEthernet3/1/1] pppoe-server bind virtual-template 10 [Router-GigabitEthernet3/1/1] quit # Create a DHCPv6 address pool named pool1 and specify DNS server IPv6 address 2:2::3. [Router] ipv6 dhcp pool pool1 [Router-dhcp6-pool-pool1] dns-server 2:2::3 [Router-dhcp6-pool-pool1] quit # Configure a PPPoE user. [Router] local-user user1 class network [Router-luser-network-user1] password simple pass1 [Router-luser-network-user1] service-type ppp [Router-luser-network-user1] quit # Configure local authentication for the PPP users in the default ISP domain (system). [Router] domain name system [Router-isp-system] authentication ppp local # Configure an IPv6 prefix and a DHCPv6 address pool authorized to the user in the ISP domain. [Router-isp-system] authorization-attribute ipv6-prefix 2003:: 64 [Router-isp-system] authorization-attribute ipv6-pool pool1 [Router-isp-system] quit Verifying the configuration # Display PPP user information on GigabitEthernet 3/1/1. [Router] display ppp access-user interface gigabitethernet 3/1/1 Interface Username MAC address IP address IPv6 address IPv6 PDPrefix BAS0 user e08-9d ::9CBC:3898:0:

297 Example: Assigning the PPPoE server IPv6 address through DHCPv6 Network configuration As shown in Figure 95, configure the PPPoE server to assign an IPv6 address to the host through DHCPv6. Figure 95 Network diagram Procedure # Create Virtual-Template 10. <Router> system-view [Router] interface virtual-template 10 # Configure Virtual-Template 10 to use PAP to authenticate the peer. [Router-Virtual-Template10] ppp authentication-mode pap domain system # Configure an IPv6 address for Virtual-Template 10. [Router-Virtual-Template10] ipv6 address 3001::1 64 # Enable Virtual-Template 10 to advertise RA messages. [Router-Virtual-Template10] undo ipv6 nd ra halt # Configure the host to use the DHCPv6 protocol to obtain IPv6 addresses. [Router-Virtual-Template10] ipv6 nd autoconfig managed-address-flag # Enable the DHCPv6 server feature. [Router-Virtual-Template10] ipv6 dhcp select server [Router-Virtual-Template10] quit # Enable the PPPoE sever on GigabitEthernet 3/1/1, and bind the interface to Virtual-Template 10. [Router] interface gigabitethernet 3/1/1 [Router-GigabitEthernet3/1/1] pppoe-server bind virtual-template 10 [Router-GigabitEthernet3/1/1] quit # Configure DHCPv6 address pool 1 with network 3001::/32 and DNS server IP address 2001:2::3. [Router] ipv6 dhcp pool pool1 [Router-dhcp6-pool-pool1] network 3001::/32 [Router-dhcp6-pool-pool1] dns-server 2001:2::3 [Router-dhcp6-pool-pool1] quit # Configure a PPPoE user. [Router] local-user user1 class network [Router-luser-network-user1] password simple pass1 [Router-luser-network-user1] service-type ppp [Router-luser-network-user1] quit # Configure an IPv6 pool attribute authorized to the user in the ISP domain. [Router] domain system [Router-isp-system] authorization-attribute ipv6-pool pool1 281

298 [Router-isp-system] quit Verifying the configuration # Display PPP user information on GigabitEthernet 3/1/1. [Router] display ppp access-user interface gigabitethernet 3/1/1 Interface Username MAC address IP address IPv6 address IPv6 PDPrefix BAS0 user e08-9d ::2 - Example: Assigning the PPPoE server IPv6 address through prefix delegation by DHCPv6 Network configuration As shown in Figure 96, configure the PPPoE server to assign a prefix to Router A through DHCPv6. Router A then assigns the prefix to the host for it to generate an IPv6 address. Figure 96 Network diagram Procedure # Create Virtual-Template 10. <RouterB> system-view [RouterB] interface virtual-template 10 # Configure Virtual-Template 10 to use PAP to authenticate the peer. [RouterB-Virtual-Template10] ppp authentication-mode pap domain system # Configure an IPv6 address for Virtual-Template 10. [RouterB-Virtual-Template10] ipv6 address 2001::1 64 # Enable Virtual-Template 10 to advertise RA messages. [RouterB-Virtual-Template10] undo ipv6 nd ra halt # Enable the DHCPv6 server feature. [RouterB-Virtual-Template10] ipv6 dhcp select server [RouterB-Virtual-Template10] quit # Enable the PPPoE sever on GigabitEthernet 3/1/1, and bind the interface to Virtual-Template 10. [RouterB] interface gigabitethernet 3/1/1 [RouterB-GigabitEthernet3/1/1] pppoe-server bind virtual-template 10 [RouterB-GigabitEthernet3/1/1] quit # Create prefix pool 6, and specify prefix 4001::/32 with assigned prefix length 42. [RouterB] ipv6 dhcp prefix-pool 6 prefix 4001::/32 assign-len 42 # Create address pool 1, specify the subnet 4001::/64 for dynamic allocation in pool 1, and apply prefix pool 6 to address pool 1. Configure DNS server IP address 2:2::3. [RouterB] ipv6 dhcp pool pool1 [RouterB-dhcp6-pool-pool1] network 4001::/64 [RouterB-dhcp6-pool-pool1] prefix-pool 6 [RouterB-dhcp6-pool-pool1] dns-server 2:2::3 282

299 [Router-dhcp6-pool-pool1] quit # Configure a PPPoE user. [RouterB] local-user user1 class network [RouterB-luser-network-user1] password simple pass1 [RouterB-luser-network-user1] service-type ppp [RouterB-luser-network-user1] quit # Configure an IPv6 pool attribute authorized to the user in the ISP domain. [RouterB] domain system [RouterB-isp-system] authorization-attribute ipv6-pool pool1 Verifying the configuration # Verify that Router B has assigned a prefix to Router A. [RouterB] display ipv6 dhcp server pd-in-use Pool: 1 IPv6 prefix Type Lease expiration 4001::1/42 Auto(O) Jul 10 19:45: Then, Router A can assign the prefix 4001::1/42 to the host who uses the prefix to generate an IPv6 global unicast address. Example: Configuring PPPoE server RADIUS-based IP address assignment Network configuration As shown in Figure 97, configure the PPPoE server to meet the following requirements: The PPPoE server uses the RADIUS server to perform authentication, authorization, and accounting for access users The RADIUS server assigns access users a PPP address pool named pool1 and a VPN instance named vpn1. Users in vpn1 obtain IP addresses from PPP address pool pool1. Figure 97 Network diagram RADIUS server /24 GE3/1/2 VPN /24 GE3/1/1 GE3/1/1 MPLS backbone /24 VPN 1 PE 1 PE 2 Host A L2 Switch Router A Router B CE PPPoE client Gateway: /24 PPPoE server P 283

300 Procedure 1. Configure the MPLS L3VPN feature. For the two ends of VPN 1 to communicate with each other, specify the same route target attributes on the two PEs (Router A and Router B). This example describes only the authentication-related configuration on the PE that is connected to the PPPoE client. For information about configuring MPLS L3VPN, see MPLS Configuration Guide. 2. Configure the RADIUS server: This example uses Free RADIUS that runs in the Linux operating system. # Add the following text to the client.conf file to configure RADIUS client information. client /24 { secret = radius shortname = sr88 } Where, secret represents the shared key for authentication, authorization, and accounting. # Add the following text to the users.conf file to configure legal user information. user1 Auth-Type == CHAP,User-Password := pass1 Service-Type = Framed-User, Framed-Protocol = PPP, Framed-IPv6-Pool = "pool1", H3C-VPN-Instance = "vpn1", 3. Configure Router A: a. Configure the PPPoE server: # Configure Virtual-Template 1 to use CHAP for authentication and use ISP domain dm1 as the authentication domain. <RouterA> system-view [RouterA] interface virtual-template 1 [RouterA-Virtual-Template1] ppp authentication-mode chap domain dm1 [RouterA-Virtual-Template1] quit # Create a PPP address pool that contains nine assignable IP addresses. [RouterA] ip pool pool group 1 # Specify gateway address and VPN instance vpn1 for pool1. [RouterA] ip pool pool1 gateway vpn-instance vpn1 # Configure a PPP address pool route for pool1. [RouterA] ppp ip-pool route vpn-instance vpn1 # Enable the PPPoE server on GigabitEthernet 3/1/1, and bind the interface to Virtual-Template 1. [RouterA] interface gigabitethernet 3/1/1 [RouterA-GigabitEthernet3/1/1] pppoe-server bind virtual-template 1 [RouterA-GigabitEthernet3/1/1] quit b. Configure a RADIUS scheme: # Create a RADIUS scheme named rs1, and enter its view. [RouterA] radius scheme rs1 # Specify the primary authentication server and the primary accounting server. [RouterA-radius-rs1] primary authentication [RouterA-radius-rs1] primary accounting # Set the shared key for secure communication with the server to radius in plain text. [RouterA-radius-rs1] key authentication simple radius 284

301 [RouterA-radius-rs1] key accounting simple radius # Exclude domain names in the usernames sent to the RADIUS server. [RouterA-radius-rs1] user-name-format without-domain [RouterA-radius-rs1] quit c. Configure an authentication domain: # Create an ISP domain named dm1. [RouterA] domain dm1 # In ISP domain dm1, perform RADIUS authentication, authorization, and accounting for users based on scheme rs1. [RouterA-isp-dm1] authentication ppp radius-scheme rs1 [RouterA-isp-dm1] authorization ppp radius-scheme rs1 [RouterA-isp-dm1] accounting ppp radius-scheme rs1 [RouterA-isp-dm1] quit Verifying the configuration # Verify that Host A can successfully ping CE. (Details not shown.) # Verify that the PPPoE client has obtained an IP address from pool1. [RouterA] display ip pool pool1 Group name: 1 Pool name Start IP address End IP address Free In use pool In use IP addresses: IP address Interface BAS0 285

302 Configuring portal authentication About portal Portal authentication controls user access to networks. Portal authenticates a user by the username and password the user enters on a portal authentication page. 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 H3C 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. 286

303 Figure 98 Portal system Authentication client Portal authentication server Portal Web server Authentication client Access device AAA server Authentication client Security policy server Authentication client Access device Portal server AAA server 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 H3C inode client is supported. 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. 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. 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 287

304 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 H3C 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 99, 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 99 System components Portal page customization To provide the local portal web service, you must customize a set of authentication pages that the device will push to users. You can customize multiple sets of authentication pages, compress each set of the pages to a.zip file, and upload the compressed files to the storage medium of the device. On the device, you must specify one of the files as the default authentication page file by using the default-logon-page command. 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 288

305 websites. After passing authentication, the user can access other network resources. The process of direct authentication is simpler than that of re-dhcp authentication. 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 H3C 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 100 Direct authentication/cross-subnet authentication process Authentication client Portal Web server 1) Initiate a connection 2) User information Portal authentication server Timer 3) CHAP authentication 4) Authentication request 6) Authentication reply Access device 5) RADIUS authentication AAA server Security policy server 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. 289

306 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. 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 101 Re-DHCP authentication process The re-dhcp authentication process is as follows: 290

307 Step 1 through step 7 are the same as those in the direct authentication/cross-subnet authentication process. 1. 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. 2. The portal authentication server notifies the access device that the client has obtained a public IP address. 3. 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. 4. 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. 5. The portal authentication server sends an IP change acknowledgment packet to the access device. Step 13 and step 14 are for extended portal functions. 6. 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. 7. 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 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: First category The rule permits user packets that are destined for the portal Web server and packets that match the portal-free rules to pass through. Second category 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. Third category The rule redirects all HTTP or HTTPS requests from unauthenticated users to the portal Web server. Fourth category 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 the first category to the fourth category. Once the packet matches a rule, the matching process completes. MAC-based quick portal authentication MAC-based quick portal authentication is applicable to scenarios where users access the network frequently. It allows users to pass authentication without entering a username and password. MAC-based quick portal authentication is also called MAC-trigger authentication or transparent portal authentication. A MAC binding server is required for MAC-trigger authentication. The MAC binding server records the MAC-to-account bindings of portal users for authentication. The account contains the portal authentication information of the user, including username and password. Only IPv4 direct authentication supports MAC-based quick portal authentication. The authentication is implemented as follows: 291

308 1. When a user accesses the network for the first time, the access device generates a MAC-trigger entry that records the user's MAC address and access interface. The user can access the network without performing portal authentication if the user's network traffic is below the free-traffic threshold. 2. When the user's network traffic reaches the threshold, the access device sends a MAC binding query to the MAC binding server. 3. The MAC binding server checks whether the MAC address of the user is bound with a portal user account. If a matching MAC-account binding exists, the MAC binding server sends the user authentication information to the access device to initiate portal authentication. The user is authenticated without entering the username and password. If the user fails portal authentication, an authentication failure message is returned to the user. The MAC-trigger entry of the user on the access device is deleted when the entry ages out. If the user passes portal authentication, the access device deletes the MAC-trigger entry of the user. If no matching MAC-account binding exists, the MAC binding server notifies the access device to perform normal portal authentication for the user. If the user fails portal authentication, an authentication failure message is returned to the user. The whole process is finished. If the user passes portal authentication, the access device sends the user's MAC address and authentication information to the MAC binding server for MAC-account binding. Additionally, the access device deletes the MAC-trigger entry of the user. NOTE: For information about MAC binding server configuration, see the user manual of the server. Restrictions: Hardware compatibility with portal Portal is supported only on the CSPEX cards. Restrictions and guidelines: Portal configuration When you configure portal, follow these restrictions and guidelines: Portal authentication through Web does not support security check for users. To implement security check, the client must be the H3C inode client. Portal authentication supports NAT traversal whether it is initiated by a Web client or an H3C 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 tasks at a glance Tasks at a glance (Optional.) Configuring a portal authentication server Configuring a portal Web server: (Required.) Configure basic parameters for a portal Web server (Optional.) Configuring a match rule for URL redirection Remarks N/A N/A 292

309 Tasks at a glance (Optional.) Configuring a local portal Web service (Optional.) Specifying a portal authentication domain (Optional.) Configuring a portal preauthentication policy (Optional.) Specifying a preauthentication IP address pool (Required.) Enabling portal authentication on an interface (Required.) Specifying a portal Web server on an interface (Optional.) Controlling portal user access Configuring a portal-free rule Configuring an authentication source subnet 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 Configuring support of Web proxy for portal authentication Blocking portal users that fail portal authentication Enabling portal roaming Configuring the portal fail-permit feature (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 (Optional.) Configuring portal packet attributes Configuring the BAS-IP or BAS-IPv6 attribute Specifying the device ID (Optional.) Configuring attributes for RADIUS packets Specifying a format for the NAS-Port-Id attribute Applying a NAS-ID profile to an interface (Optional.) Configuring MAC-based quick portal authentication (Optional.) Configuring portal HTTP attack defense (Optional.) Setting the user traffic backup threshold (Optional.) Logging out online portal users (Optional.) Enabling portal user login/logout logging (Optional.) Configuring Web redirect Remarks N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A On Etherchannel interfaces, both Web redirect and portal authentication can be enabled at the same time. On non-ethernetchannel interfaces, Web redirect does not work when both Web redirect and portal authentication are enabled. 293

310 Prerequisites for portal The portal feature provides a solution for user identity authentication and security check. To complete user identity authentication, portal must cooperate with RADIUS. The prerequisites for portal authentication configuration are as follows: 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 security ACL on the security policy server. For information about security policy server configuration on the access device, see "Configuring AAA." 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 portal authentication server Configure this feature when user authentication uses a remote portal authentication server. 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. To configure a portal authentication server: 2. Create a portal authentication server, and enter its view. 3. Specify the IP address of the portal authentication server. portal server server-name To specify an IPv4 portal server: ip ipv4-address [ vpn-instance ipv4-vpn-instance-name] [ key { cipher simple } string ] To specify an IPv6 portal server: ipv6 ipv6-address [ vpn-instance ipv6-vpn-instance-name] [ key { cipher simple } string ] 294 By default, no portal authentication servers exist. You can create multiple portal authentication servers. Do not delete a portal authentication server in use. Otherwise, users authenticated by that server cannot log out correctly. Specify an IPv4 portal authentication server or an IPv6 authentication portal server. By default, no portal authentication server is specified.

311 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 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. 6. (Optional.) Set the interval at which the device registers with a portal authentication server. server-type { cmcc imc } server-register [ interval interval-value ] 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. By default, the device does not register with a portal authentication server. Configuring a portal Web server Configure basic parameters for a portal Web server 2. Create a portal Web server and enter its view. 3. Specify the VPN instance to which the portal Web server belongs. 4. Specify the URL of the portal Web server. 5. Configure the parameters to be carried in the URL when the device redirects it to users. 6. (Optional.) Specify the portal Web server type. portal web-server server-name vpn-instance vpn-instance-name url url-string url-parameter param-name { nas-id nas-port-id original-url source-address source-mac [ encryption { aes des } key { cipher simple } string ] value expression } server-type { cmcc imc } By default, no portal Web servers exist. You can create multiple portal Web servers. By default, the portal Web server belongs to the public network. By default, no URL is specified. By default, no redirection URL parameters are configured. By default, the portal Web server type is IMC. The specified server type must be the same as the type of the portal Web server actually used. This command is applicable to only remote portal authentication. 295

312 Configuring a match rule for URL redirection A URL redirection match rule matches HTTP or HTTPS requests by user-requested URL or User-Agent information, and redirects the matching HTTP or HTTPS requests to the specified redirection URL. 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. For a portal Web server, you can configure the url command and the if-match command for URL redirection. The url command redirects all HTTP or HTTPS requests from unauthenticated users to the portal Web server for authentication. The if-match command allows for flexible URL redirection by redirecting specific HTTP or HTTPS requests to specific redirection URLs. If both commands are executed, the if-match command takes priority to perform URL redirection. To configure a match rule for URL redirection: 2. Create a portal Web server and enter its view. 3. Configure a match rule for URL redirection. portal web-server server-name 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 } By default, no portal Web servers exist. By default, no URL redirection match rules exist. Configuring a local portal Web service Restrictions and guidelines for configuring a local portal Web service When you configure a local portal Web service, follow these restrictions and guidelines: For an interface to use the local portal Web 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 ) on the device, and the IP address must be reachable to portal clients. The URL must be ended with /portal/. For example: You must customize the authentication pages and upload them to the device. Customizing authentication pages Authentication pages are HTML files. Local portal authentication requires the following authentication pages: Logon page Logon success page Logon failure page Online page 296

313 File name rules 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. The names of the main authentication page files are fixed (see Table 14). You can define the names of the files other than the main authentication page files. File names and directory names are case insensitive. Table 14 Main authentication page file names Main authentication page Logon page Logon success page Logon failure page Online page Pushed after the user gets online for online notification System busy page Pushed when the system is busy or the user is in the logon process Logoff success page File name logon.htm logonsuccess.htm logonfail.htm online.htm busy.htm logoffsuccess.htm Page request rules The local portal Web service 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. 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;"> 297

314 </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 Feb :53:20 ssid1.zip 0 -rw Feb :53:31 ssid2.zip 2 -rw Feb :53:39 ssid3.zip 3 -rw Feb :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 logonsucceess.htm. See the contents in gray: <html> <head> <title>logonsuccessed</title> <script type="text/javascript" language="javascript" src="pt_private.js"></script> </head> <body onload="pt_init();" onbeforeunload="return pt_unload();"> </body> </html> Configuring parameters for a local portal Web service Prerequisites To provide an HTTPS-based local portal Web service, you must configure an SSL server 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 298

315 Procedure name of the policy must be https_redirect. For more information about SSL server policy configuration, see SSL configuration in Security Configuration Guide. To configure the parameters for a local portal Web service: 2. Create an HTTP- or HTTPS-based local portal Web service and enter its view. portal local-web-server { http https ssl-server-policy policy-name } By default, no local portal Web service exists. 3. Specify the default authentication page file for the local portal Web service. 4. (Optional.) Configure the listening TCP port for the local portal Web service. default-logon-page filename tcp-port port-number By default, no default authentication page file is specified for the local portal Web service. To provide local portal Web service for users, you must use this command to specify a customized authentication page file as the default authentication page file. By default, the HTTP service listening port number is 80 and the HTTPS service listening port number is 443. 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 chooses an authentication domain for each user in the following order: 1. The authentication domain specified for portal users. 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. If no such ISP domain is configured, user authentication fails. For more information about ISP domains, see "Configuring AAA." 299

316 Specifying a portal authentication domain on an interface 2. Enter interface view. 3. Specify an portal authentication domain on the interface. interface interface-type interface-number portal [ ipv6 ] domain domain-name N/A 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. Configuring a portal preauthentication policy About portal preauthentication policies A portal preauthentication policy defines user attributes assigned to preauthentication portal users on a portal-enabled interface after the users obtain IP addresses. Before the preauthentication users pass portal authentication, they have limited access to the network based on the assigned user attributes (such as ACL, user profile, and CAR). After the users pass portal authentication, they are assigned new attributes by the AAA server. After the users go offline, they are re-assigned user attributes in the preauthentication policy. Restrictions and guidelines Procedure When you configure a portal preauthentication policy, follow these restrictions and guidelines: The portal preauthentication policy takes effect only on portal users with IP addresses obtained through DHCP or DHCPv6. The portal preauthentication policy does not take effect on interfaces enabled with cross-subnet portal authentication. If you modify a user attribute (or its contents) in the portal preauthentication policy, the modification immediately takes effect on the policy-applied interface for unauthenticated portal users. To configure a portal preauthentication policy: 2. Create a portal preauthentication policy and enter its view. portal pre-auth policy policy-name By default, no portal preauthentication policies exist. 300

317 3. Configure a user attribute in the portal preauthentication policy. user-attribute { acl acl-number car { inbound outbound } cir committed-information-rate [ pir peak-information-rate ] user-profile profile-name } 4. Return to system view. quit N/A By default, no user attributes are configured for a portal preauthentication policy. 5. Enter interface view. 6. Apply a portal preauthentication policy to the interface. interface interface-type interface-number portal [ ipv6 ] apply pre-auth-policy policy-name N/A By default, no portal preauthentication policy is applied to an interface. Specifying a preauthentication IP address pool About preauthentication IP address pools 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. However, if the interface does not have an IP address, users using static IP addresses cannot pass authentication. 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. Restrictions and guidelines When you specify a preauthentication IP address pool, follow these guidelines and restrictions: 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. 301

318 Procedure To specify a preauthentication IP address pool: 2. Enter interface view. 3. Specify a preauthentication IP address pool on the interface. interface interface-type interface-number portal [ ipv6 ] pre-auth ip-pool pool-name N/A By default, no preauthentication IP address pool is specified on an interface. Enabling portal authentication on an interface Restrictions and guidelines General restrictions and guidelines for enabling portal authentication When you enable portal authentication on an interface, follow these restrictions and guidelines: If the device is connected to the RADIUS and portal servers through interfaces on SPC, CSPC, and CMPE-1104 cards, set the UDP port numbers as follows: Set the RADIUS authentication and accounting port numbers to 1812 and 1813, respectively. Set the portal listening port number to For more information about specifying the port numbers for RADIUS authentication and RADIUS accounting on the device, see "Configuring AAA." You can enable both IPv4 portal authentication and IPv6 portal authentication on an interface. Portal authentication does not take effect on a tunnel interface. Do not add the Ethernet interface enabled with portal authentication to an aggregation group. Otherwise, portal authentication does not take effect. As a best practice, do not apply a QoS policy to an interface enabled with portal authentication by using the qos apply policy command. If you need to apply a QoS policy on the interface, do it under the guidance of the technical support. For more information about the qos apply policy command, see ACL and QoS Command Reference. If you assign an Ethernet interface enabled with portal authentication to an aggregation group, portal authentication takes effect on the aggregate interface instead of aggregation member ports. Restrictions and guidelines for enabling cross-subnet portal authentication When you configure cross-subnet portal authentication (layer3) on an interface, follow these restrictions and guidelines: IPv6 portal users that pass cross-subnet portal authentication on the interface cannot receive IPv6 multicast data after the users join IPv6 multicast groups. For more information about users' joining IPv6 multicast groups, see MLD configuration in IP Multicast Configuration Guide. Cross-subnet portal authentication 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. 302

319 Restrictions and guidelines for enabling re-dhcp portal authentication When you configure re-dhcp portal authentication (re-dhcp) on an interface, follow these restrictions and guidelines: Make sure the interface has a valid IP address before you enable re-dhcp portal authentication on the interface. For re-dhcp portal authentication to take effect after the IP address of the interface changes, you must disable portal authentication and then enable re-dhcp portal authentication. 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/BAS-IPv6 attribute value is the same as the device IP or IPv6 address specified on the portal authentication server. To configure the BAS-IP/BAS-IPv6 attribute, use the portal { bas-ip bas-ipv6 } command. An IPv6 portal server does not support re-dhcp portal authentication. Procedure To enable portal authentication on an interface: 2. Enter interface view. 3. Enable portal authentication. interface interface-type interface-number To enable IPv4 portal authentication: portal enable method { direct layer3 redhcp } To enable IPv6 portal authentication: portal ipv6 enable method { direct layer3 } The following types of interfaces are supported: Layer 3 Ethernet interface. Layer 3 Ethernet subinterface. VLAN interface. Layer 3 aggregate interface. Layer 3 aggregate subinterface. Enable IPv4 portal authentication, IPv6 portal authentication, or both on the interface. By default, portal authentication is disabled. Specifying a portal Web server on an interface 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. To specify a portal Web server on an interface: 303

320 2. Enter interface view. interface interface-type interface-number 3. Specify a portal Web server on the interface. To specify an IPv4 portal Web server: portal apply web-server server-name [ fail-permit ] To specify an IPv6 portal Web server: portal ipv6 apply web-server server-name [ fail-permit ] The following types of interfaces are supported: Layer 3 Ethernet interface. Layer 3 Ethernet subinterface. VLAN interface. Layer 3 aggregate interface. Layer 3 aggregate subinterface. Specify an IPv4 portal Web server, an IPv6 portal Web server, or both. By default, no portal Web servers are specified on an interface. Controlling portal user access Configuring a portal-free rule About portal-free rules 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 When you configure a portal-free rule, follow these restrictions and guidelines: 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. When you configure an IP-based portal-free rule, follow these restrictions and guidelines: If a portal-enabled interface is enabled with the static individual users feature of IPoE, you must specify the source IP address in the portal-free rule. Make sure the specified source IP address is not the same as any of the trusted source IP addresses for unclassified-ip users. The trusted source IP addresses for unclassified-ip users are configured by using the ip subscriber unclassified-ip ip match or ipv6 subscriber unclassified-ip ip match command. For more information about the static individual users feature, see "Configuring IPoE." For more information about the ip subscriber unclassified-ip ip match and ipv6 subscriber unclassified-ip ip match commands, see IPoE commands in BRAS Services Command Reference. 304

321 If a portal-enabled interface is enabled with the DHCP users feature of IPoE, you must specify the source IP address in the portal-free rule. Make sure the specified source IP address is not the same as any of the IP addresses that the DHCP server assigns to IPoE users. For more information about enabling the DHCP users feature, see "Configuring IPoE." Configuring an IP-based portal-free rule 2. Configure an IPv4-based portal-free rule. 3. Configure an IPv6-based portal-free rule. 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 ] 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 ] By default, no IPv4-based portal-free rule exists. By default, no IPv6-based portal-free rule exists. Configuring a source-based portal-free rule 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 } * By default, no source-based portal-free rule exists. 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 2. Configure a destination-based portal-free rule. portal free-rule rule-number destination host-name By default, no destination-based portal-free rule exists. Configuring an authentication source subnet By configuring authentication source subnets, you specify that only HTTP or HTTPS packets from users on the authentication source subnets can trigger portal authentication. If an unauthenticated user is not on any authentication source subnet, the access device discards all the user's HTTP or HTTPS packets that do not match any portal-free rule. 305

322 Restrictions and guidelines for configuring an authentication source subnet When you configure a portal authentication source subnet, follow these restrictions and guidelines: Authentication source subnets apply only to cross-subnet portal 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. If the specified authentication source subnet is different from the access subnet of the users, the users will fail the portal authentication. 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. 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. Configuring an IPv4 portal authentication source subnet 2. Enter interface view. 3. Configure an IPv4 portal authentication source subnet. interface interface-type interface-number portal layer3 source ipv4-network-address { mask-length mask } N/A By default, no IPv4 portal authentication source subnet is configured, and users from any subnets must pass portal authentication. Configuring an IPv6 portal authentication source subnet 2. Enter interface view. 3. Configure an IPv6 portal authentication source subnet. interface interface-type interface-number portal ipv6 layer3 source ipv6-network-address prefix-length N/A By default, no IPv6 portal authentication source subnet is configured, and IPv6 users from any subnets must pass portal authentication. Setting the maximum number of portal users 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 system-allowed maximum number. Otherwise, the exceeding number of portal users will not be able to log in to the device. Setting the global maximum 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. 306

323 To set the global maximum number of portal users: 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. Setting the maximum 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. To set the maximum number of portal users on an interface: 2. Enter interface view. 3. Set the maximum number of portal users. interface interface-type interface-number portal { ipv4-max-user ipv6-max-user } max-number N/A By default, no limit is set on the number of portal users. Enabling strict-checking on portal authorization information IMPORTANT: The user profile feature fails temporarily when an active/standby MPU switchover finishes, and it resumes after user information synchronization completes between the global active MPU and service modules. You can use the display device command or check the LEDs on cards to see whether an active/standby MPU switchover finishes. For more information about the display device command, see device management commands in Fundamentals Command Reference. About strict-checking on portal authorization information The strict checking mode allows a portal user to stay online only when the authorized information for the user is successfully deployed on the interface. You can enable strict checking on authorized ACLs, authorized user profiles, or both. If you enable both ACL checking and user profile checking, the user will be logged out if either checking fails. An ACL/user profile checking fails when the authorized ACL/user profile does not exist on the device or the ACL/user profile fails to be deployed. Enabling strict checking on portal authentication information on an interface 2. Enter interface view. interface interface-type interface-number N/A 307

324 3. Enable strict checking on portal authorization information. portal authorization { acl user-profile } strict-checking By default, strict checking on portal authentication information is disabled on an interface. In this case, the portal users stay online even when the authorized ACLs or user profiles do not exist or fail to be deployed. Allowing only users with DHCP-assigned IP addresses to pass portal authentication To ensure that only users with valid IP addresses access the network, enable this feature on an interface. This feature allows only users with DHCP-assigned IP addresses to pass portal authentication. Users with static IP addresses cannot pass portal authentication to get online. Restrictions and guidelines Procedure When you configure this feature, follow these restrictions and guidelines: To ensure that IPv6 users can pass portal authentication when only users with DHCP-assigned IP addresses to 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. This configuration does not affect the online portal users. To allow only users with DHCP-assigned IP addresses to pass portal authentication: 2. Enter interface view. 3. Allow only users with DHCP-assigned IP addresses to pass portal authentication. interface interface-type interface-number portal [ ipv6 ] user-dhcp-only N/A By default, both users with IP addresses obtained through DHCP and users with static IP addresses can pass authentication to come online. Configuring support of Web proxy for portal authentication About the support of Web proxy for portal authentication To allow HTTP requests proxied by a Web proxy server to trigger portal authentication, specify the TCP 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. 308

325 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. 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 To configure support of Web proxy for portal authentication: 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. Blocking portal users that fail portal authentication This feature prevents exhaustive password cracking. It blocks a portal user if the user consecutively fails authentication for the specified times within the failure detection period. All authentication requests from the user are dropped by the device till the blocking times out. The blocked portal user can perform portal authentication again when the blocking timeout time expires. This feature does not block preauthentication portal users. To block portal users that fail portal authentication: 2. Configure the device to block portal users that fail portal authentication for the specified times within the specified period. 3. Set the portal user blocking timeout time. portal user-block failed-times failed-times period period portal user-block reactive period By default, the device does not block portal users that fail portal authentication. If you set the failed-times argument to 0, the device does not block portal users that fail portal authentication. By default, the portal user blocking timeout time is 30 minutes. If you set the portal user blocking timeout time to 0 minutes, blocked portal users cannot perform portal authentication. Enabling portal roaming About portal roaming 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. 309

326 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 When you enable portal roaming, follow these 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 or preauthentication portal users exist on the device. Procedure To enable portal roaming: 2. Enable portal roaming. portal roaming enable By default, portal roaming is disabled. Configuring the portal fail-permit feature 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. To configure portal fail-permit on an interface: 2. Enter interface view. 3. Enable portal fail-permit for a portal authentication server. 4. Enable portal fail-permit for a portal Web server. interface interface-type interface-number portal [ ipv6 ] fail-permit server server-name portal [ ipv6 ] apply web-server server-name [ fail-permit ] N/A By default, portal fail-permit is disabled for a portal authentication server. By default, portal fail-permit is disabled for a portal Web server. 310

327 Configuring portal detection features Configuring online detection of portal users About online detection for portal users Configure online detection 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. 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 detecting the user's ARP or ND entry. 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 for configuring online user detection ARP and ND detections apply only to direct and re-dhcp portal authentication. ICMP detection applies to all portal authentication modes. Configuring online detection for IPv4 portal users 2. Enter interface view. 3. Configure online detection of IPv4 portal users. interface interface-type interface-number portal user-detect type { arp icmp } [ retry retries ] [ interval interval ] [ idle time ] N/A By default, this feature is disabled on the interface. Configuring online detection for IPv6 portal users 2. Enter interface view. 3. Configure online detection of IPv6 portal users. interface interface-type interface-number portal ipv6 user-detect type { icmpv6 nd } [ retry retries ] [ interval interval ] [ idle time ] N/A By default, this feature is disabled on the interface. 311

328 Configuring portal authentication server detection About portal authentication server detection 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 When you configure portal authentication server detection, follow these 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: Sending a trap message to the NMS. The trap message contains the name and current state of the portal authentication server. 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 To configure portal authentication server detection: 2. Enter portal authentication server view. portal server server-name N/A 3. Configure portal authentication server detection. server-detect [ timeout timeout ] { log trap } * By default, portal authentication server detection is disabled. This feature takes effect regardless of whether portal authentication is enabled on an interface or not. 312

329 Configuring portal Web server detection About portal Web server detection Procedure 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. 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. 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 trap message to the NMS. The trap message contains the name and current state of the portal Web server. 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." To configure portal Web server detection: 2. Enter portal Web server view. portal web-server server-name N/A 3. Configure portal Web server detection. server-detect [ interval interval ] [ retry retries ] { log trap } * By default, portal Web server detection is disabled. This feature takes effect regardless of whether portal authentication is enabled on an interface or not. Configuring portal user synchronization About portal user synchronization 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 313

330 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 When you configure portal user synchronization, follow these 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 To configure portal user information synchronization: 2. Enter portal authentication server view. 3. Configure portal user synchronization. portal server server-name user-sync timeout timeout N/A By default, portal user synchronization is disabled. Configuring portal packet attributes Configuring the BAS-IP or BAS-IPv6 attribute About the BAS-IP or BAS-IPv6 attribute in portal packets 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. 314

331 Restrictions and guidelines Procedure When you configure the BAS-IP or BAS-IPv6 attribute for portal packets sent to the portal authentication server, follow these 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 or IPv6 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 H3C IMC server. The portal device IP address specified on the portal authentication server is not the IP address of the portal packet output interface. To configuring the BAS-IP or BAS-IPv6 attribute: 2. Enter interface view. 3. Configure the BAS-IP attribute. 4. Configure the BAS-IPv6 attribute. interface interface-type interface-number portal bas-ip ipv4-address portal bas-ipv6 ipv6-address N/A By default: The BAS-IP attribute of an IPv4 portal reply packet sent to the portal authentication server is the source IPv4 address of the packet. The BAS-IP attribute of an IPv4 portal notification packet sent to the portal authentication server is the IPv4 address of the packet's output interface. By default: The BAS-IPv6 attribute of an IPv6 portal reply packet sent to the portal authentication server is the source IPv6 address of the packet. The BAS-IPv6 attribute of an IPv6 portal notification packet sent to the portal authentication server is the IPv6 address of the packet's output interface. Specifying the device ID The portal authentication server uses device IDs to identify the devices that send protocol packets to the portal server. Make sure the configured device ID is different than any other access devices communicating with the same portal authentication server. To specify the device ID: 315

332 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 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 format (format 1, 2, 3, and 4) and the custom format. For more information about the formats, see the portal nas-port-id format command in BRAS Services Command Reference. To specify a format for the NAS-Port-Id attribute: 2. Specify the format for the NAS-Port-Id attribute. portal nas-port-id format { custom { c-vid [ delimiter ] interface-type [ delimiter ] port [ delimiter ] slot [ delimiter ] subslot [ delimiter ] s-vid [ delimiter ] string string [ delimiter ] } * } By default, the format for the NAS-Port-Id attribute is format 2. Applying a NAS-ID profile to an interface 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. 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. To apply a NAS-ID profile to an interface: 2. Create a NAS-ID profile and enter NAS-ID profile view. 3. Configure a NAS ID and VLAN binding in the profile. aaa nas-id profile profile-name nas-id nas-identifier bind { vlan vlan-id { c-vid vlan-id s-vid vlan-id } * } For more information about this command, see BRAS Services Command Reference. For more information about this command, see BRAS Services Command Reference. 316

333 4. Return to system view. quit N/A 5. Enter interface view. 6. Specify the NAS-ID profile on the interface. interface interface-type interface-number portal nas-id-profile profile-name N/A By default, no NAS-ID profile is specified on the interface. Configuring MAC-based quick portal authentication Restrictions and guidelines for configuring MAC-based quick portal authentication Only IPv4 direct authentication supports MAC-based quick portal authentication. Do not configure both a MAC binding server and a portal preauthentication policy on an interface. Otherwise, the MAC binding server does not take effect. Configuring a MAC binding server You can configure multiple MAC binding servers on the device. Perform this task to configure MAC binding server parameters, such as the server's IP address and the free-traffic threshold. To configure a MAC binding server: 2. Create a MAC binding server and enter its view. 3. Specify the IP address of the MAC binding server. 4. (Optional.) Specify the free-traffic threshold. 5. (Optional.) Specify the NAS-Port-Type value carried in RADIUS requests sent to the RADIUS server. 6. (Optional.) Set the UDP port number on which the MAC binding server listens for MAC binding query packets. 7. (Optional.) Specify the maximum number of attempts and the interval for sending MAC binding queries to the MAC binding server. portal mac-trigger-server server-name ip ipv4-address [ vpn-instance ipv4-vpn-instance-name ] [ key { cipher simple } string ] free-traffic threshold value nas-port-type value port port-number binding-retry { retries interval interval } * By default, no MAC binder servers exist. By default, the IP address of a MAC binding server is not specified. By default, the free-traffic threshold is 0 bytes. By default, the NAS-Port-Type value carried in RADIUS requests is 0. By default, the MAC binding server listens for MAC binding query packets on UDP port By default, the maximum number of query attempts is 3 and the query interval is 1 second. 317

334 8. (Optional.) Specify the type of the MAC binding server 9. (Optional.) Specify the version of the portal protocol. 10. (Optional.) Specify the timeout the device waits for portal authentication to complete after receiving the MAC binding query response. server-type { cmcc imc } version version-number authentication-timeout minutes By default, the type of a MAC binding server is IMC. By default, the version of the portal protocol is 1. By default, the portal authentication timeout time is 3 minutes. 11. (Optional.) Set the aging time for MAC-trigger entries. aging-time seconds By default, the aging time for MAC-trigger entries is 300 seconds. Specifying a MAC binding server on an interface After a MAC binding server is specified on an interface, the device can implement MAC-based quick portal authentication for portal users on the interface. To specify a MAC binding server on an interface: 2. Enter interface view. 3. Specify a MAC binding server on the interface. interface interface-type interface-number portal apply mac-trigger-server server-name The interface must be a Layer 3 interface. By default, no MAC binding server is specified on an interface. Configuring portal HTTP attack defense About portal HTTP attack defense Procedure Use this feature to avoid high resource usage caused by excessive HTTP requests from unauthenticated portal users. This feature counts the number of HTTP requests to be redirected on a per destination IP address basis. If the number of HTTP requests for a destination IP address reaches the blocking threshold within a statistical interval, the device starts a blocking timer for the IP address. Before the blocking timer expires, the device discards all HTTP requests destined for the IP address. You can set the maximum number of destination IP addresses for which the device can perform portal HTTP attack defense. To configure portal HTTP attack defense: 2. Enable portal HTTP attack defense. portal http-defense enable By default, portal HTTP attack defense is disabled. 318

335 3. Set the portal HTTP attack defense parameters. portal http-defense { block-timeout minutes statistics-interval value threshold number } * By default, the blocking timer is 10 minutes, the statistical interval for counting redirected HTTP packets is 5 minutes, and the blocking threshold is 6000 packets. 4. Set the maximum number of destination IP addresses for portal HTTP attack defense. portal http-defense max-ip-number max-ip-number By default, the device can perform portal HTTP attack defense for a maximum of 4096 destination IP addresses. Setting the user traffic backup threshold About setting the user traffic backup threshold Procedure The device backs up traffic for a user when the user's traffic reaches the user traffic backup threshold. A smaller threshold provides more accurate backup for user traffic. However, when a large number of users exist, a small threshold results in frequent user traffic backups, affecting the user online, offline, and accounting processes. Set a proper threshold to balance between service performance and traffic backup accuracy. To set the user traffic backup threshold: 2. Set the user traffic backup threshold. portal traffic-backup threshold value By default, the user traffic backup threshold is 10 MB. Logging out online portal users This feature deletes users that have passed portal authentication and terminates ongoing portal authentications. 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 perform the following operations during the command execution: Active/standby MPU switchover. Disabling portal authentication on the interface. To log out online users: Step Command 1. Enter system view. system-view 2. Log out IPv4 online portal users. 3. Log out IPv6 online portal users. portal delete-user { ipv4-address all interface interface-type interface-number session-id session-id username username } portal delete-user { all interface interface-type interface-number ipv6 ipv6-address session-id session-id username username } 319

336 Enabling portal user login/logout logging This feature logs information about user login and logout events, including 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. To enable portal user login/logout logging: 2. Enable portal user login/logout logging. portal user log enable [ abnormal-logout failed-login normal-logout successful-login ] * By default, portal user login/logout logging is disabled. Configuring Web redirect About Web redirect 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 Procedure When you configure Web redirect, follow these restrictions and guidelines: On Etherchannel interfaces, both Web redirect and portal authentication can be enabled at the same time. On non-etherchannel interfaces, Web redirect does not work when both Web redirect and portal authentication are enabled. The Web redirect feature takes effect only on HTTP packets that use the default port number 80 and HTTPS packets that use the default port number 443. To configure Web redirect: 2. Enter interface view. 3. Configure Web redirect. interface interface-type interface-number web-redirect [ ipv6 ] url url-string [ interval interval ] N/A By default, Web redirect is disabled. 320

337 Display and maintenance commands for portal Execute display commands in any view and the reset command in user view. Task (In standalone mode.) Display statistics for attacked destination IP addresses in portal HTTP attack defense. (In IRF mode.) Display statistics for attacked destination IP addresses in portal HTTP attack defense. (In standalone mode.) Display statistics for blocked destination IP addresses in portal HTTP attack defense. (In IRF mode.) Display statistics for blocked destination IP addresses in portal HTTP attack defense. (In standalone mode.) Display the counts of destination IP addresses in portal HTTP attack defense. (In IRF mode.) Display the counts of destination IP addresses in portal HTTP attack defense. (In standalone mode.) Display statistics for monitored destination IP addresses in portal HTTP attack defense. (In IRF mode.) Display statistics for monitored destination IP addresses in portal HTTP attack defense. Display portal configuration and portal running state information. Display information about MAC binding servers. (In standalone mode.) Display portal rules. (In IRF mode.) Display portal rules. Command display portal http-defense attacked-ip [ slot slot-number ] display portal http-defense attacked-ip [ chassis chassis-number slot slot-number ] display portal http-defense blocked-ip [ slot slot-number ] display portal http-defense blocked-ip [ chassis chassis-number slot slot-number ] display portal http-defense ip-count [ slot slot-number ] display portal http-defense ip-count [ chassis chassis-number slot slot-number ] display portal http-defense monitored-ip [ slot slot-number ] display portal http-defense monitored-ip [ chassis chassis-number slot slot-number ] display portal interface interface-type interface-number display portal mac-trigger-server { all name server-name } display portal rule { all dynamic static } { interface interface-type interface-number [ slot slot-number ] } display portal rule { all dynamic static } { interface interface-type interface-number [ chassis chassis-number slot slot-number ] } Display portal authentication server information. display portal server [ server-name ] Display portal Web server information. display portal web-server [ server-name ] Display packet statistics for portal authentication servers. Display portal user information. (In standalone mode.) Clear statistics for attacked destination IP addresses in portal HTTP attack defense. display portal packet statistics [ server server-name ] display portal user { all interface interface-type interface-number ip ipv4-address ipv6 ipv6-address pre-auth [ interface interface-type interface-number ip ipv4-address ipv6 ipv6-address ] } [ verbose ] reset portal http-defense attacked-ip [ slot slot-number ] 321

338 Task (In IRF mode.) Clear statistics for attacked destination IP addresses in portal HTTP attack defense. (In standalone mode.) Clear statistics for blocked destination IP addresses in portal HTTP attack defense. (In IRF mode.) Clear statistics for blocked destination IP addresses in portal HTTP attack defense. Clear packet statistics for portal authentication servers. (In standalone mode.) Display Web redirect rule information. (In IRF mode.) Display Web redirect rule information. Command reset portal http-defense attacked-ip [ chassis chassis-number slot slot-number ] reset portal http-defense blocked-ip [ ip ipv4-address ipv6 ipv6-address ] [ slot slot-number ] reset portal http-defense blocked-ip [ ip ipv4-address ipv6 ipv6-address ] [ chassis chassis-number slot slot-number ] reset portal packet statistics [ server server-name ] display web-redirect rule interface interface-type interface-number [ slot slot-number ] display web-redirect rule interface interface-type interface-number [ chassis chassis-number slot slot-number ] Portal configuration examples Example: Configuring direct portal authentication Network configuration As shown in Figure 102, the host is directly connected to the router (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/accounting server. 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 102 Network diagram GE1/0/ /24 GE1/0/ /24 Portal server /24 Host /24 Gateway: /24 Router RADIUS server /24 Configuration prerequisites Configure IP addresses for the host, router, and servers as shown in Figure 102 and make sure they can reach each other. Configure the RADIUS server correctly to provide authentication and accounting functions. 322

339 Configuring the portal authentication server on IMC PLAT 3.20 In this example, the portal server runs on IMC PLAT 3.20-R2602P13 and IMC UAM 3.60-E Configure the portal authentication server: a. Log in to IMC and click the Service tab. b. Select Access Service > Portal Service Management > Server from the navigation tree to open the portal server configuration page, as shown in Figure 103. c. Configure the portal server parameters as needed. This example uses the default values. d. Click OK. Figure 103 Portal authentication server configuration 2. Configure the IP address group: a. Select Access Service > Portal Service Management > 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 104. 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. Figure 104 Adding an IP address group 3. Add a portal device: 323

340 a. Select Access Service > Portal Service Management > Device from the navigation tree to open the portal device configuration page. b. Click Add to open the page as shown in Figure 105. c. Enter the device name NAS. d. Enter the IP address of the router's interface connected to the host. e. Enter the key, which must be the same as that configured on the router. f. Set whether to enable IP address reallocation. This example uses direct portal authentication, and therefore select No from the Reallocate IP list. g. 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. h. Click OK. Figure 105 Adding a portal device 4. Associate the portal device with the IP address group: a. As shown in Figure 106, click the icon in the Port Group Information Management column of device NAS to open the port group configuration page. Figure 106 Device list b. Click Add to open the page as shown in Figure

341 Figure 107 Port group configuration 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. Click OK. 5. Select Access Service > Service Parameters > Validate System Configuration from the navigation tree to validate the configurations. Configuring the portal authentication server on IMC PLAT 5.0 In this example, the portal server runs on IMC PLAT 5.0(E0101) and IMC UAM 5.0(E0101). 1. Configure the portal authentication server: a. Log in to IMC and click the Service tab. b. Select User Access Manager > Portal Service Management > Server from the navigation tree to open the portal server configuration page, as shown in Figure 108. c. Configure the portal server parameters as needed. This example uses the default settings. d. Click OK. 325

342 Figure 108 Portal server configuration 2. Configure the IP address group: a. Select User Access Manager > Portal Service Management > 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 109. 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. Figure 109 Adding an IP address group 3. Add a portal device: 326

343 a. Select User Access Manager > Portal Service Management > Device from the navigation tree to open the portal device configuration page. b. Click Add to open the page as shown in Figure 110. c. Enter the device name NAS. d. Enter the IP address of the router's interface connected to the host. e. Enter the key, which must be the same as that configured on the router. f. Set whether to enable IP address reallocation. This example uses direct portal authentication, and therefore select No from the Reallocate IP list. g. Select whether to support server heartbeat and user heartbeat functions. In this example, select No for both Support Server Heartbeat and Support User Heartbeat. h. Click OK. Figure 110 Adding a portal device 4. Associate the portal device with the IP address group: a. As shown in Figure 111, click the icon in the Port Group Information Management column of device NAS to open the port group configuration page. b. Click Add to open the page as shown in Figure 112. 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 111 Device list 327

344 Figure 112 Adding a port group 5. Select User Access Manager > Service Parameters > Validate System Configuration from the navigation tree to validate the configurations. Configuring the router 1. Configure a RADIUS scheme: # Create a RADIUS scheme named rs1 and enter its view. <Router> system-view [Router] radius scheme rs1 # Specify the primary authentication server and primary accounting server, and configure the keys for communication with the servers. [Router-radius-rs1] primary authentication [Router-radius-rs1] primary accounting [Router-radius-rs1] key authentication simple radius [Router-radius-rs1] key accounting simple radius # Exclude the ISP domain name from the username sent to the RADIUS server. [Router-radius-rs1] user-name-format without-domain [Router-radius-rs1] quit # Enable RADIUS session control. [Router] radius session-control enable 2. Configure an authentication domain: # Create an ISP domain named dm1 and enter its view. [Router] domain dm1 # Configure AAA methods for the ISP domain. [Router-isp-dm1] authentication portal radius-scheme rs1 [Router-isp-dm1] authorization portal radius-scheme rs1 [Router-isp-dm1] accounting portal radius-scheme rs1 [Router-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. [Router] domain default enable dm1 3. Configure portal authentication: 328

345 # Configure a portal authentication server. [Router] portal server newpt [Router-portal-server-newpt] ip key simple portal [Router-portal-server-newpt] port [Router-portal-server-newpt] quit # Configure a portal Web server. [Router] portal web-server newpt [Router-portal-websvr-newpt] url [Router-portal-websvr-newpt] quit # Enable direct portal authentication on GigabitEthernet 1/0/2. [Router] interface gigabitethernet 1/0/2 [Router GigabitEthernet1/0/2] portal enable method direct # Reference the portal Web server newpt on GigabitEthernet 1/0/2. [Router GigabitEthernet1/0/2] portal apply web-server newpt # Configure the BAS-IP as for portal packets sent from GigabitEthernet 1/0/2 to the portal authentication server. [Router GigabitEthernet1/0/2] portal bas-ip [Router GigabitEthernet1/0/2] quit Verifying the configuration # Verify that the portal configuration has taken effect. [Router] display portal interface gigabitethernet 1/0/2 Portal information of GigabitEthernet 1/0/2 NAS-ID profile: Not configured Authorization : Strict checking ACL : Disabled User profile : Disabled IPv4: Portal status: Enabled Portal authentication method: Direct Portal web server: newpt Authentication domain: Not configured Pre-auth policy: Not configured User-dhcp-only: Disabled Pre-auth IP pool: Not configured Max Portal users: Not configured Bas-ip: 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 329

346 Portal web server: Not configured Authentication domain: Not configured Pre-auth policy: Not configured User-dhcp-only: Disabled Pre-auth IP pool: Not configured Max Portal 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 330 Prefix length A user can perform portal authentication by using the H3C inode client or through a Web browser. Before passing the authentication, the user can access only the authentication page 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. [Router] display portal user interface gigabitethernet 1/0/2 Total portal users: 1 Username: abc Portal server: newpt State: Online VPN instance: N/A MAC IP VLAN Interface 0015-e9a6-7cfe GigabitEthernet1/0/2 Authorization information: DHCP IP pool: N/A User profile: N/A Session group profile: N/A ACL: N/A Inbound CAR: N/A Outbound CAR: N/A Inbound priority: N/A Outbound priority: N/A Example: Configuring re-dhcp portal authentication Network configuration As shown in Figure 113, the host is directly connected to the router (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/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.

347 Figure 113 Network diagram Configuration prerequisites and guidelines Procedure Configure IP addresses for the router and servers as shown in Figure 113 and make sure the host, router, and servers can reach each other. Configure the RADIUS server correctly to provide authentication and accounting functions. For re-dhcp portal authentication, configure a public address pool ( /24) and a private address pool ( /24) on the DHCP server. (Details not shown.) For re-dhcp portal authentication: The router 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 "Configuring DHCP." Make sure the IP address of the portal device added on the portal server is the public IP address ( ) of the router's interface connecting the host. The private IP address range for the IP address group associated with the portal device is the private subnet /24 where the host resides. The public IP address range for the IP address group is the public subnet /24. Perform the following tasks on the router. 1. Configure a RADIUS scheme: # Create a RADIUS scheme named rs1 and enter its view. <Router> system-view [Router] radius scheme rs1 # Specify the primary authentication server and primary accounting server, and configure the keys for communication with the servers. [Router-radius-rs1] primary authentication [Router-radius-rs1] primary accounting [Router-radius-rs1] key authentication simple radius [Router-radius-rs1] key accounting simple radius # Exclude the ISP domain name from the username sent to the RADIUS server. [Router-radius-rs1] user-name-format without-domain [Router-radius-rs1] quit # Enable RADIUS session control. 331

348 [Router] radius session-control enable 2. Configure an authentication domain: # Create an ISP domain named dm1 and enter its view. [Router] domain dm1 # Configure AAA methods for the ISP domain. [Router-isp-dm1] authentication portal radius-scheme rs1 [Router-isp-dm1] authorization portal radius-scheme rs1 [Router-isp-dm1] accounting portal radius-scheme rs1 [Router-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. [Router] domain default enable dm1 3. Configure DHCP relay and authorized ARP: # Configure DHCP relay. [Router] dhcp enable [Router] dhcp relay client-information record [Router] interface gigabitethernet 1/0/2 [Router GigabitEthernet1/0/2] ip address [Router GigabitEthernet1/0/2] ip address sub [Router-GigabitEthernet1/0/2] dhcp select relay [Router-GigabitEthernet1/0/2] dhcp relay server-address # Enable authorized ARP. [Router-GigabitEthernet1/0/2] arp authorized enable [Router-GigabitEthernet1/0/2] quit 4. Configure portal authentication: # Configure a portal authentication server. [Router] portal server newpt [Router-portal-server-newpt] ip key simple portal [Router-portal-server-newpt] port [Router-portal-server-newpt] quit # Configure a portal Web server. [Router] portal web-server newpt [Router-portal-websvr-newpt] url [Router-portal-websvr-newpt] quit # Enable re-dhcp portal authentication on GigabitEthernet 1/0/2. [Router] interface gigabitethernet 1/0/2 [Router-GigabitEthernet1/0/2] portal enable method redhcp # Reference the portal Web server newpt on GigabitEthernet 1/0/2. [Router GigabitEthernet1/0/2] portal apply web-server newpt # Configure the BAS-IP as for portal packets sent from GigabitEthernet 1/0/2 to the portal authentication server. [Router GigabitEthernet1/0/2] portal bas-ip [Router GigabitEthernet1/0/2] quit Verifying the configuration # Verify that the portal configuration has taken effect. [Router] display portal interface gigabitethernet 1/0/2 332

349 Portal information of GigabitEthernet1/0/2 NAS-ID profile: Not configured Authorization : Strict checking ACL : Disabled User profile : Disabled IPv4: Portal status: Enabled Portal authentication method: Redhcp Portal web server: newpt Authentication domain: Not configured Pre-auth policy: Not configured User-dhcp-only: Disabled Pre-auth IP pool: Not configured Max Portal users: Not configured Bas-ip: 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 Authentication domain: Not configured Pre-auth policy: Not configured User-dhcp-only: Disabled Pre-auth IP pool: Not configured Max Portal 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 333 Prefix length Before passing the authentication, a user that uses the H3C inode client can access only the authentication page 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.

350 [Router] display portal user interface gigabitethernet 1/0/2 Total portal users: 1 Username: abc Portal server: newpt State: Online VPN instance: N/A MAC IP VLAN Interface 0015-e9a6-7cfe GigabitEthernet1/0/2 Authorization information: DHCP IP pool: N/A User profile: N/A Session group profile: N/A ACL: N/A Inbound CAR: N/A Outbound CAR: N/A Inbound priority: N/A Outbound priority: N/A Example: Configuring cross-subnet portal authentication Network configuration As shown in Figure 114, Router A supports portal authentication. The host accesses Router A through Router B. A portal server acts as both a portal authentication server and a portal Web server. A RADIUS server acts as the authentication/accounting server. Configure Router A for cross-subnet portal authentication. Before passing the authentication, the host can access only the portal server. After passing the authentication, the user can access other network resources. Figure 114 Network diagram Configuration prerequisites and guidelines Configure IP addresses for the router and servers as shown in Figure 114 and make sure the host, router, and servers can reach each other. Configure the RADIUS server correctly to provide authentication and accounting functions. Make sure the IP address of the portal device added on the portal authentication server is the IP address ( ) of the router's interface connecting the host. The IP address group associated with the portal device is the subnet of the host ( /24). 334

351 Procedure Perform the following tasks on Router A. 1. Configure a RADIUS scheme: # Create a RADIUS scheme named rs1 and enter its view. <RouterA> system-view [RouterA] radius scheme rs1 # Specify the primary authentication server and primary accounting server, and configure the keys for communication with the servers. [RouterA-radius-rs1] primary authentication [RouterA-radius-rs1] primary accounting [RouterA-radius-rs1] key authentication simple radius [RouterA-radius-rs1] key accounting simple radius # Exclude the ISP domain name from the username sent to the RADIUS server. [RouterA-radius-rs1] user-name-format without-domain [RouterA-radius-rs1] quit # Enable RADIUS session control. [RouterA] radius session-control enable 2. Configure an authentication domain: # Create an ISP domain named dm1 and enter its view. [RouterA] domain dm1 # Configure AAA methods for the ISP domain. [RouterA-isp-dm1] authentication portal radius-scheme rs1 [RouterA-isp-dm1] authorization portal radius-scheme rs1 [RouterA-isp-dm1] accounting portal radius-scheme rs1 [RouterA-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. [RouterA] domain default enable dm1 3. Configure portal authentication: # Configure a portal authentication server. [RouterA] portal server newpt [RouterA-portal-server-newpt] ip key simple portal [RouterA-portal-server-newpt] port [RouterA-portal-server-newpt] quit # Configure a portal Web server. [Router] portal web-server newpt [RouterA-portal-websvr-newpt] url [RouterA-portal-websvr-newpt] quit # Enable cross-subnet portal authentication on GigabitEthernet 1/0/2. [RouterA] interface gigabitethernet 1/0/2 [RouterA GigabitEthernet1/0/2] portal enable method layer3 # Reference the portal Web server newpt on GigabitEthernet 1/0/2. [RouterA GigabitEthernet1/0/2] portal apply web-server newpt # Configure the BAS-IP as for portal packets sent from GigabitEthernet 1/0/2 to the portal authentication server. [RouterA GigabitEthernet1/0/2] portal bas-ip

352 [RouterA GigabitEthernet1/0/2] quit On Router B, configure a default route to subnet /24, specifying the next hop address as (Details not shown.) Verifying the configuration # Verify that the portal configuration has taken effect. [RouterA] display portal interface gigabitethernet 1/0/2 Portal information of GigabitEthernet1/0/2 NAS-ID profile: Not configured Authorization : Strict checking ACL : Disabled User profile : Disabled IPv4: Portal status: Enabled Portal authentication method: Layer3 Portal web server: newpt Authentication domain: Not configured Pre-auth policy: Not configured User-dhcp-only: Disabled Pre-auth IP pool: Not configured Max Portal users: Not configured Bas-ip: 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 Authentication domain: Not configured Pre-auth policy: Not configured User-dhcp-only: Disabled Pre-auth IP pool: Not configured Max Portal 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: 336

353 IP address Prefix length A user can perform portal authentication by using the H3C inode client or through a Web browser. Before passing the authentication, the user can access only the authentication page 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. [RouterA] display portal user interface gigabitethernet 1/0/2 Total portal users: 1 Username: abc Portal server: newpt State: Online VPN instance: N/A MAC IP VLAN Interface 0015-e9a6-7cfe GigabitEthernet1/0/2 Authorization information: DHCP IP pool: N/A User profile: N/A Session group profile: N/A ACL: N/A Inbound CAR: N/A Outbound CAR: N/A Inbound priority: N/A Outbound priority: N/A Example: Configuring extended direct portal authentication Network configuration As shown in Figure 115, the host is directly connected to the router (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/accounting server. Configure extended direct portal authentication. If the host fails security check after passing identity authentication, it can access only subnet /24. After passing security check, the host can access other network resources. 337

354 Figure 115 Network diagram Portal server /24 GE1/0/ /24 GE1/0/ /24 Host /24 Gateway: /24 Router RADIUS server /24 Security policy server /24 Configuration prerequisites Procedure Configure IP addresses for the host, router, and servers as shown in Figure 115 and make sure they can reach each other. Configure the RADIUS server correctly to provide authentication and accounting functions. Perform the following tasks on the router. 1. Configure a RADIUS scheme: # Create a RADIUS scheme named rs1 and enter its view. <Router> system-view [Router] radius scheme rs1 # Specify the primary authentication server and primary accounting server, and configure the keys for communication with the servers. [Router-radius-rs1] primary authentication [Router-radius-rs1] primary accounting [Router-radius-rs1] key accounting simple radius [Router-radius-rs1] key authentication simple radius [Router-radius-rs1] user-name-format without-domain # Enable RADIUS session control. [Router] radius session-control enable # Specify a session-control client with IP address and shared key in plain text. [Router] radius session-control client ip key simple Configure an authentication domain: # Create an ISP domain named dm1 and enter its view. [Router] domain dm1 # Configure AAA methods for the ISP domain. [Router-isp-dm1] authentication portal radius-scheme rs1 [Router-isp-dm1] authorization portal radius-scheme rs1 [Router-isp-dm1] accounting portal radius-scheme rs1 [Router-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. 338

355 [Router] domain default enable dm1 3. Configure ACL 3000 as the isolation ACL and ACL 3001 as the security ACL. [Router] acl advanced 3000 [Router-acl-ipv4-adv-3000] rule permit ip destination [Router-acl-ipv4-adv-3000] rule deny ip [Router-acl-ipv4-adv-3000] quit [Router] acl advanced 3001 [Router-acl-ipv4-adv-3001] rule permit ip [Router-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. [Router] portal server newpt [Router-portal-server-newpt] ip key simple portal [Router-portal-server-newpt] port [Router-portal-server-newpt] quit # Configure a portal Web server. [Router] portal web-server newpt [Router-portal-websvr-newpt] url [Router-portal-websvr-newpt] quit # Enable direct portal authentication on GigabitEthernet 1/0/2. [Router] interface gigabitethernet 1/0/2 [Router GigabitEthernet1/0/2] portal enable method direct # Reference the portal Web server newpt on GigabitEthernet 1/0/2. [Router GigabitEthernet1/0/2] portal apply web-server newpt # Configure the BAS-IP as for portal packets sent from GigabitEthernet 1/0/2 to the portal authentication server. [Router GigabitEthernet1/0/2] portal bas-ip [Router GigabitEthernet1/0/2] quit Verifying the configuration # Verify that the portal configuration has taken effect. [Router] display portal interface gigabitethernet 1/0/2 Portal information of GigabitEthernet1/0/2 NAS-ID profile: Not configured Authorization : Strict checking ACL : Disabled User profile : Disabled IPv4: Portal status: Enabled Portal authentication method: Direct Portal web server: newpt Authentication domain: Not configured Pre-auth policy: Not configured User-dhcp-only: Disabled 339

356 Pre-auth IP pool: Not configured Max Portal users: Not configured Bas-ip: 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 Authentication domain: Not configured Pre-auth policy: Not configured User-dhcp-only: Disabled Pre-auth IP pool: Not configured Max Portal 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 340 Prefix length Before passing portal authentication, a user that uses the H3C inode client can access only the authentication page 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. [Router] display portal user interface gigabitethernet 1/0/2 Total portal users: 1 Username: abc Portal server: newpt State: Online VPN instance: N/A MAC IP VLAN Interface 0015-e9a6-7cfe GigabitEthernet1/0/2 Authorization information:

357 DHCP IP pool: N/A User profile: N/A Session group profile: N/A ACL: 3001 Inbound CAR: N/A Outbound CAR: N/A Inbound priority: N/A Outbound priority: N/A Example: Configuring extended re-dhcp portal authentication Network configuration As shown in Figure 116, the host is directly connected to the router (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/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 /24. After passing the security check, the host can access other network resources. Figure 116 Network diagram Configuration prerequisites and guidelines Configure IP addresses for the router and servers as shown in Figure 116 and make sure the host, router, and servers can reach each other. Configure the RADIUS server correctly to provide authentication and accounting functions. For re-dhcp portal authentication, configure a public address pool ( /24) and a private address pool ( /24) on the DHCP server. (Details not shown.) For re-dhcp portal authentication: The router 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 "Configuring DHCP." 341

358 Procedure Make sure the IP address of the portal device added on the portal server is the public IP address ( ) of the router's interface connecting the host. The private IP address range for the IP address group associated with the portal device is the private subnet /24 where the host resides. The public IP address range for the IP address group is the public subnet /24. Perform the following tasks on the router. 1. Configure a RADIUS scheme: # Create a RADIUS scheme named rs1 and enter its view. <Router> system-view [Router] radius scheme rs1 # Specify the primary authentication server and primary accounting server, and configure the keys for communication with the servers. [Router-radius-rs1] primary authentication [Router-radius-rs1] primary accounting [Router-radius-rs1] key authentication simple radius [Router-radius-rs1] key accounting simple radius [Router-radius-rs1] user-name-format without-domain # Enable RADIUS session control. [Router] radius session-control enable # Specify a session-control client with IP address and shared key in plain text. [Router] radius session-control client ip key simple Configure an authentication domain: # Create an ISP domain named dm1 and enter its view. [Router] domain dm1 # Configure AAA methods for the ISP domain. [Router-isp-dm1] authentication portal radius-scheme rs1 [Router-isp-dm1] authorization portal radius-scheme rs1 [Router-isp-dm1] accounting portal radius-scheme rs1 [Router-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. [Router] domain default enable dm1 3. Configure ACL 3000 as the isolation ACL and ACL 3001 as the security ACL. [Router] acl advanced 3000 [Router-acl-ipv4-adv-3000] rule permit ip destination [Router-acl-ipv4-adv-3000] rule deny ip [Router-acl-ipv4-adv-3000] quit [Router] acl advanced 3001 [Router-acl-ipv4-adv-3001] rule permit ip [Router-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: 342

359 # Configure DHCP relay. [Router] dhcp enable [Router] dhcp relay client-information record [Router] interface gigabitethernet 1/0/2 [Router GigabitEthernet1/0/2] ip address [Router GigabitEthernet1/0/2] ip address sub [Router-GigabitEthernet1/0/2] dhcp select relay [Router-GigabitEthernet1/0/2] dhcp relay server-address # Enable authorized ARP. [Router-GigabitEthernet1/0/2] arp authorized enable [Router-GigabitEthernet1/0/2] quit 5. Configure portal authentication: # Configure a portal authentication server. [Router] portal server newpt [Router-portal-server-newpt] ip key simple portal [Router-portal-server-newpt] port [Router-portal-server-newpt] quit # Configure a portal Web server. [Router] portal web-server newpt [Router-portal-websvr-newpt] url [Router-portal-websvr-newpt] quit # Enable re-dhcp portal authentication on GigabitEthernet 1/0/2. [Router] interface gigabitethernet 1/0/2 [Router-GigabitEthernet1/0/2] portal enable method redhcp # Reference the portal Web server newpt on GigabitEthernet 1/0/2. [Router GigabitEthernet1/0/2] portal apply web-server newpt # Configure the BAS-IP as for portal packets sent from GigabitEthernet 1/0/2 to the portal authentication server. [Router GigabitEthernet1/0/2] portal bas-ip [Router GigabitEthernet1/0/2] quit Verifying the configuration # Verify that the portal configuration has taken effect. [Router] display portal interface gigabitethernet 1/0/2 Portal information of GigabitEthernet1/0/2 NAS-ID profile: Not configured Authorization : Strict checking ACL : Disabled User profile : Disabled IPv4: Portal status: Enabled Portal authentication method: Redhcp Portal web server: newpt Authentication domain: Not configured Pre-auth policy: Not configured User-dhcp-only: Disabled Pre-auth IP pool: Not configured Max Portal users: Not configured 343

360 Bas-ip: 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 Authentication domain: Not configured Pre-auth policy: Not configured User-dhcp-only: Disabled Pre-auth IP pool: Not configured Max Portal 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 344 Prefix length Before passing portal authentication, a user that uses the H3C inode client can access only the authentication page 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. [Router] display portal user interface gigabitethernet 1/0/2 Total portal users: 1 Username: abc Portal server: newpt State: Online VPN instance: N/A MAC IP VLAN Interface 0015-e9a6-7cfe GigabitEthernet1/0/2 Authorization information: DHCP IP pool: N/A User profile: N/A

361 Session group profile: N/A ACL: 3001 Inbound CAR: N/A Outbound CAR: N/A Inbound priority: N/A Outbound priority: N/A Example: Configuring extended cross-subnet portal authentication Network configuration As shown in Figure 117, Router A supports portal authentication. The host accesses Router A through Router B. A portal server acts as both a portal authentication server and a portal Web server. A RADIUS server acts as the authentication/accounting server. Configure Router 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 /24. After passing the security check, the host can access other network resources. Figure 117 Network diagram GE1/0/ /24 GE1/0/ /24 Router A GE1/0/ /24 GE1/0/ /24 Portal server /24 RADIUS server /24 Host /24 Router B Security policy server /24 Configuration prerequisites and guidelines Procedure Configure IP addresses for the router and servers as shown in Figure 117 and make sure the host, router, and servers can reach each other. Configure the RADIUS server correctly to provide authentication and accounting functions. Make sure the IP address of the portal device added on the portal server is the IP address ( ) of the router's interface connecting the host. The IP address group associated with the portal device is the subnet of the host ( /24). Perform the following tasks on Router A. 1. Configure a RADIUS scheme: # Create a RADIUS scheme named rs1 and enter its view. <RouterA> system-view [RouterA] radius scheme rs1 345

362 # Specify the primary authentication server and primary accounting server, and configure the keys for communication with the servers. [RouterA-radius-rs1] primary authentication [RouterA-radius-rs1] primary accounting [RouterA-radius-rs1] key authentication simple radius [RouterA-radius-rs1] key accounting simple radius [RouterA-radius-rs1] user-name-format without-domain # Enable RADIUS session control. [RouterA] radius session-control enable # Specify a session-control client with IP address and shared key in plain text. [RouterA] radius session-control client ip key simple Configure an authentication domain: # Create an ISP domain named dm1 and enter its view. [RouterA] domain dm1 # Configure AAA methods for the ISP domain. [RouterA-isp-dm1] authentication portal radius-scheme rs1 [RouterA-isp-dm1] authorization portal radius-scheme rs1 [RouterA-isp-dm1] accounting portal radius-scheme rs1 [RouterA-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. [RouterA] domain default enable dm1 3. Configure ACL 3000 as the isolation ACL and ACL 3001 as the security ACL. [RouterA] acl advanced 3000 [RouterA-acl-ipv4-adv-3000] rule permit ip destination [RouterA-acl-ipv4-adv-3000] rule deny ip [RouterA-acl-ipv4-adv-3000] quit [RouterA] acl advanced 3001 [RouterA-acl-ipv4-adv-3001] rule permit ip [RouterA-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. [RouterA] portal server newpt [RouterA-portal-server-newpt] ip key simple portal [RouterA-portal-server-newpt] port [RouterA-portal-server-newpt] quit # Configure a portal Web server. [Router] portal web-server newpt [RouterA-portal-websvr-newpt] url [RouterA-portal-websvr-newpt] quit # Enable cross-subnet portal authentication on GigabitEthernet 1/0/2. [RouterA] interface gigabitethernet 1/0/2 346

363 [RouterA GigabitEthernet1/0/2] portal enable method layer3 # Reference the portal Web server newpt on GigabitEthernet 1/0/2. [RouterA GigabitEthernet1/0/2] portal apply web-server newpt # Configure the BAS-IP as for portal packets sent from GigabitEthernet 1/0/2 to the portal authentication server. [RouterA GigabitEthernet1/0/2] portal bas-ip [RouterA GigabitEthernet1/0/2] quit On Router B, configure a default route to subnet /24, specifying the next hop address as (Details not shown.) Verifying the configuration # Verify that the portal configuration has taken effect. [RouterA] display portal interface gigabitethernet 1/0/2 Portal information of GigabitEthernet 1/0/2 NAS-ID profile: Not configured Authorization : Strict checking ACL : Disabled User profile : Disabled IPv4: Portal status: Enabled Portal authentication method: Layer3 Portal web server: newpt Authentication domain: Not configured Pre-auth policy: Not configured User-dhcp-only: Disabled Pre-auth IP pool: Not configured Max Portal users: Not configured Bas-ip: 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 Authentication domain: Not configured Pre-auth policy: Not configured User-dhcp-only: Disabled Pre-auth IP pool: Not configured Max Portal users: Not configured Bas-ipv6: Not configured User detection: Not configured Action for server detection: 347

364 Server type Server name Action Layer3 source network: IP address Prefix length Destination authenticate subnet: IP address 348 Prefix length Before passing portal authentication, a user that uses the H3C inode client can access only the authentication page All Web requests from the user are 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. [RouterA] display portal user interface gigabitethernet 1/0/2 Total portal users: 1 Username: abc Portal server: newpt State: Online VPN instance: N/A MAC IP VLAN Interface 0015-e9a6-7cfe GigabitEthernet1/0/2 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 Inbound priority: N/A Outbound priority: N/A Example: Configuring portal server detection and portal user synchronization Network configuration As shown in Figure 118, the host is directly connected to the router (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/accounting server. Configure direct portal authentication on the router, so the host can access only the portal server before passing the authentication and access other network resources after passing the authentication. Configure the router to do the following: Detect the reachability state of the portal authentication server. Send log messages upon state changes.

365 Disable portal authentication when the authentication server is unreachable. Synchronize portal user information with the portal server periodically. Figure 118 Network diagram GE1/0/ /24 GE1/0/ /24 Portal server /24 Host /24 Gateway: /24 Router RADIUS server /24 Configuration prerequisites and guidelines Configure IP addresses for the router and servers as shown in Figure 118 and make sure the host, router, and servers can reach each other. Configure the RADIUS server correctly to provide authentication and accounting functions. Configuring the portal authentication server on IMC PLAT 3.20 In this example, the portal server runs on IMC PLAT 3.20-R2602P13 and IMC UAM 3.60-E Configure the portal authentication server: a. Log in to IMC and click the Service tab. b. Select Access Service > Portal Service Management > Server from the navigation tree to open the portal server configuration page, as shown in Figure 119. c. Configure the portal server heartbeat interval and user heartbeat interval. d. Use the default settings for other parameters. e. Click OK. Figure 119 Portal authentication server configuration 2. Configure the IP address group: a. Select Access Service > Portal Service Management > 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 120. c. Enter the IP group name. 349

366 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. Figure 120 Adding an IP address group 3. Add a portal device: a. Select Access Service > Portal Service Management > Device from the navigation tree to open the portal device configuration page. b. Click Add to open the page as shown in Figure 121. c. Enter the device name NAS. d. Enter the IP address of the router's interface connected to the host. e. Enter the key, which must be the same as that configured on the router. f. Set whether to enable IP address reallocation. This example uses direct portal authentication, and therefore select No from the Reallocate IP list. g. 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. h. Click OK. Figure 121 Adding a portal device 350

367 4. Associate the portal device with the IP address group: a. As shown in Figure 122, click the icon in the Port Group Information Management column of device NAS to open the port group configuration page. Figure 122 Device list b. Click Add to open the page as shown in Figure 123. Figure 123 Port group configuration 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. User default values for other parameters. f. Click OK. 5. Select Access Service > Service Parameters > Validate System Configuration from the navigation tree to validate the configurations. Configuring the portal authentication server on IMC PLAT 5.0 In this example, the portal server runs on IMC PLAT 5.0(E0101) and IMC UAM 5.0(E0101). 1. Configure the portal authentication server: a. Log in to IMC and click the Service tab. b. Select User Access Manager > Portal Service Management > Server from the navigation tree to open the portal server configuration page, as shown in Figure 124. c. Configure the portal server heartbeat interval and user heartbeat interval. d. Use the default settings for other parameters. e. Click OK. 351

368 Figure 124 Portal authentication server configuration 2. Configure the IP address group: a. Select User Access Manager > Portal Service Management > 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 125. 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. Figure 125 Adding an IP address group 3. Add a portal device: 352

369 a. Select User Access Manager > Portal Service Management > Device from the navigation tree to open the portal device configuration page. b. Click Add to open the page as shown in Figure 126. c. Enter the device name NAS. d. Enter the IP address of the router's interface connected to the host. e. Enter the key, which must be the same as that configured on the router. f. Set whether to enable IP address reallocation. This example uses direct portal authentication, and therefore select No from the Reallocate IP list. g. Select whether to support server heartbeat and user heartbeat functions. In this example, select Yes for both Support Server Heartbeat and Support User Heartbeat. h. Click OK. Figure 126 Adding a portal device 4. Associate the portal device with the IP address group: a. As shown in Figure 127, click the icon in the Port Group Information Management column of device NAS to open the port group configuration page. b. Click Add to open the page as shown in Figure 128. 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 127 Device list 353

370 Figure 128 Adding a port group 5. Select User Access Manager > Service Parameters > Validate System Configuration from the navigation tree to validate the configurations. Configuring the router 1. Configure a RADIUS scheme: # Create a RADIUS scheme named rs1 and enter its view. <Router> system-view [Router] radius scheme rs1 # Specify the primary authentication server and primary accounting server, and configure the keys for communication with the servers. [Router-radius-rs1] primary authentication [Router-radius-rs1] primary accounting [Router-radius-rs1] key authentication simple radius [Router-radius-rs1] key accounting simple radius # Exclude the ISP domain name from the username sent to the RADIUS server. [Router-radius-rs1] user-name-format without-domain [Router-radius-rs1] quit # Enable RADIUS session control. [Router] radius session-control enable 2. Configure an authentication domain: # Create an ISP domain named dm1 and enter its view. [Router] domain dm1 # Configure AAA methods for the ISP domain. [Router-isp-dm1] authentication portal radius-scheme rs1 [Router-isp-dm1] authorization portal radius-scheme rs1 [Router-isp-dm1] accounting portal radius-scheme rs1 [Router-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. [Router] domain default enable dm1 3. Configure portal authentication: 354

371 # Configure a portal authentication server. [Router] portal server newpt [Router-portal-server-newpt] ip key simple portal [Router-portal-server-newpt] port # Configure reachability detection of the portal authentication server: set the server detection interval to 40 seconds, and send log messages upon reachability status changes. [Router-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. [Router-portal-server-newpt] user-sync timeout 600 [Router-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. [Router] portal web-server newpt [Router-portal-websvr-newpt] url [Router-portal-websvr-newpt] quit # Enable direct portal authentication on GigabitEthernet 1/0/2. [Router] interface gigabitethernet 1/0/2 [Router GigabitEthernet1/0/2] portal enable method direct # Enable portal fail-permit for the portal authentication server newpt. [Router GigabitEthernet1/0/2] portal fail-permit server newpt # Reference the portal Web server newpt on GigabitEthernet 1/0/2. [Router GigabitEthernet1/0/2] portal apply web-server newpt # Configure the BAS-IP as for portal packets sent from GigabitEthernet 1/0/2 to the portal authentication server. [Router GigabitEthernet1/0/2] portal bas-ip [Router GigabitEthernet1/0/2] quit Verifying the configuration # Use the following command to display information about the portal authentication server. [Router] display portal server newpt Portal server: newpt Type : IMC IP : VPN instance : Not configured Port : 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 355

372 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 cross-subnet portal authentication for MPLS L3VPNs Network configuration As shown in Figure 129, the PE device Router A provides portal authentication for the host in VPN 1. A portal server in VPN 3 acts as the portal authentication server, portal Web server, and RADIUS server. Configure cross-subnet portal authentication on Router A, so the host can access network resources after passing identity authentication. Figure 129 Network diagram Configuration prerequisites Procedure Before enabling portal authentication, configure MPLS L3VPN and specify VPN targets for VPN 1 and VPN 3 so that VPN 1 and VPN 3 can communicate with each other. This example describes only the access authentication configuration on the user-side PE. For information about MPLS L3VPN configurations, see MPLS Configuration Guide. Configure the RADIUS server correctly to provide authentication and accounting functions. Perform the following tasks on Router A. 1. Configure a RADIUS scheme: # Create a RADIUS scheme named rs1 and enter its view. <RouterA> system-view [RouterA] radius scheme rs1 # For the RADIUS scheme, specify the VPN instance that is bound to the interface connected to the portal/radius server. This example uses VPN instance vpn3. (For information about the VPN instance, see the MPLS L3VPN configuration on Router A.) [RouterA-radius-rs1] vpn-instance vpn3 # Specify the primary authentication server and primary accounting server, and configure the keys for communication with the servers. [RouterA-radius-rs1] primary authentication [RouterA-radius-rs1] primary accounting [RouterA-radius-rs1] key accounting simple radius [RouterA-radius-rs1] key authentication simple radius # Exclude the ISP domain name from the username sent to the RADIUS server. [RouterA-radius-rs1] user-name-format without-domain 356

373 # Specify the source IP address for RADIUS packets to be sent as This address must be the same as that of the portal device specified on the portal authentication server to avoid authentication failures. [RouterA-radius-rs1] nas-ip [RouterA-radius-rs1] quit # Enable RADIUS session control. [RouterA] radius session-control enable 2. Configure an authentication domain: # Create an ISP domain named dm1 and enter its view. [RouterA] domain dm1 # Configure AAA methods for the ISP domain. [RouterA-isp-dm1] authentication portal radius-scheme rs1 [RouterA-isp-dm1] authorization portal radius-scheme rs1 [RouterA-isp-dm1] accounting portal radius-scheme rs1 [RouterA-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. [RouterA] domain default enable dm1 3. Configure portal authentication: # Configure a portal authentication server. [RouterA] portal server newpt [RouterA-portal-server-newpt] ip vpn-instance vpn3 key simple portal [RouterA-portal-server-newpt] port [RouterA-portal-server-newpt] quit # Configure a portal Web server. [RouterA] portal web-server newpt [RouterA-portal-websvr-newpt] url [RouterA-portal-websvr-newpt] vpn-instance vpn3 [RouterA-portal-websvr-newpt] quit # Enable cross-subnet portal authentication on GigabitEthernet 1/0/1. [RouterA] interface gigabitethernet 1/0/1 [RouterA GigabitEthernet1/0/1] portal enable method layer3 # Reference the portal Web server newpt on GigabitEthernet 1/0/1. [RouterA GigabitEthernet1/0/1] portal apply web-server newpt # Configure the BAS-IP as for portal packets sent from GigabitEthernet 1/0/1 to the portal authentication server. [RouterA GigabitEthernet1/0/1] portal bas-ip [RouterA GigabitEthernet1/0/1] quit Verifying the configuration # Verify the portal configuration by executing the display portal interface command. (Details not shown.) # After the user passes authentication, execute the display portal user command to display the portal user information. [RouterA] display portal user all Total portal users: 1 Username: abc Portal server: newpt 357

374 State: Online VPN instance: vpn3 MAC IP VLAN Interface GigabitEthernet1/0/1 Authorization information: DHCP IP pool: N/A User profile: N/A Session group profile: N/A ACL: N/A Inbound CAR: N/A Outbound CAR: N/A Inbound priority: N/A Outbound priority: N/A Example: Configuring direct portal authentication with a preauthentication policy Network configuration As shown in Figure 130, the host is directly connected to the router (the access device). The host is assigned a public IP address through DHCP. A portal server acts as both a portal authentication server and a portal Web server. A RADIUS server acts as the authentication/accounting server. Configure direct portal authentication, so the host can access only subnet /24 before passing the authentication and access other network resources after passing the authentication. Figure 130 Network diagram GE1/0/ /24 GE1/0/ /24 Portal server /24 Host /24 Gateway: /24 Router RADIUS server /24 Configuration prerequisites Procedure Configure IP addresses for the host, router, and servers as shown in Figure 130 and make sure they can reach each other. Configure the RADIUS server correctly to provide authentication and accounting functions. Perform the following tasks on the router. 1. Configure a preauthentication IP address pool: # Configure DHCP address pool pre to assign IP addresses and other configuration parameters to clients on subnet /24. <Router> system-view [Router] dhcp server ip-pool pre 358

375 [Router-dhcp-pool-pre] gateway-list [Router-dhcp-pool-pre] network [Router-dhcp-pool-pre] quit # Enable the DHCP server on GigabitEthernet 1/0/2. [Router] interface gigabitethernet 1/0/2 [Router GigabitEthernet1/0/2] dhcp select server [Router GigabitEthernet1/0/2] quit 2. Configure a portal preauthentication policy: # Create a portal preauthentication policy named abc. [Router] portal pre-auth policy abc # Specify user attribute ACL 3010 in the portal preauthentication policy. [Router-pre-auth-abc] user-attribute acl 3010 [Router-pre-auth-abc] quit # In ACL 3010, configure a rule to permit access to the subnet /24. [Router] acl advanced 3010 [Router-acl-ipv4-adv-3010] rule 1 permit ip destination [Router-acl-ipv4-adv-3010] quit # Apply portal preauthentication policy abc to GigabitEthernet 1/0/2. [Router] interface gigabitethernet 1/0/2 [Router GigabitEthernet1/0/2] portal apply pre-auth-policy abc [Router GigabitEthernet1/0/2] quit 3. Configure portal authentication: # Configure a portal authentication server. [Router] portal server newpt [Router-portal-server-newpt] ip key simple portal [Router-portal-server-newpt] port [Router-portal-server-newpt] quit # Configure a portal Web server. [Router] portal web-server newpt [Router-portal-websvr-newpt] url [Router-portal-websvr-newpt] quit # Enable direct portal authentication on GigabitEthernet 1/0/2. [Router] interface gigabitethernet 1/0/2 [Router GigabitEthernet1/0/2] portal enable method direct # Reference the portal Web server newpt on GigabitEthernet 1/0/2. [Router GigabitEthernet1/0/2] portal apply web-server newpt # Configure the BAS-IP as for portal packets sent from GigabitEthernet 1/0/2 to the portal authentication server. [Router GigabitEthernet1/0/2] portal bas-ip [Router GigabitEthernet1/0/2] quit Verifying the configuration # Verify the portal configuration by executing the display portal interface command. (Details not shown.) # Display information about preauthentication portal users. [Router] display portal user pre-auth interface gigabitethernet 1/0/2 MAC IP VLAN Interface 0015-e9a6-7cfe GigabitEthernet1/0/2 359

376 State: Online VPN instance: N/A Authorization information: DHCP IP pool: N/A User profile: N/A Session group profile: N/A ACL: 3010 Inbound CAR: N/A Outbound CAR: N/A Inbound priority: N/A Outbound priority: N/A Example: Configuring re-dhcp portal authentication with a preauthentication policy Network configuration As shown in Figure 131, the host is directly connected to the router (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/accounting server. Configure re-dhcp portal authentication. Before passing the authentication, the host is assigned a private IP address and can access only the subnet /24. After passing the authentication, the host gets a public IP address and can access other network resources. Figure 131 Network diagram GE1/0/ / /24 sub GE1/0/ /24 Portal server /24 Host Automatically obtains an IP address Router DHCP server /24 RADIUS server /24 Configuration prerequisites and guidelines Configure IP addresses for the router and servers as shown in Figure 131 and make sure the host, router, and servers can reach each other. Configure the RADIUS server correctly to provide authentication and accounting functions. For re-dhcp portal authentication, configure a public address pool ( /24) and a private address pool ( /24) on the DHCP server. (Details not shown.) For re-dhcp portal authentication: The router 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). 360

377 Procedure For information about DHCP relay agent configuration, see "Configuring DHCP.". Make sure the IP address of the portal device added on the portal server is the public IP address ( ) of the router's interface connecting the host. The private IP address range for the IP address group associated with the portal device is the private subnet /24 where the host resides. The public IP address range for the IP address group is the public subnet /24. If you have configured a preauthentication IP address pool on portal-enabled interfaces, configure a DHCP relay address pool with the same name on the device. For the DHCP relay address pool, specify the subnet address where the unauthenticated users reside (with the export-router keyword specified) and the DHCP server address. Perform the following tasks on the router. 1. Configure a portal preauthentication policy: # Create a portal preauthentication policy named abc. <Router> system-view [Router] portal pre-auth policy abc # Specify user attribute ACL 3010 in the portal preauthentication policy. [Router-pre-auth-abc] user-attribute acl 3010 [Router-pre-auth-abc] quit # In ACL 3010, configure a rule to permit access to the subnet /24. [Router] acl advanced 3010 [Router-acl-ipv4-adv-3010] rule 1 permit ip destination [Router-acl-ipv4-adv-3010] quit # Apply portal preauthentication policy abc to GigabitEthernet 1/0/2. [Router] interface gigabitethernet 1/0/2 [Router GigabitEthernet1/0/2] portal apply pre-auth-policy abc [Router GigabitEthernet1/0/2] quit 2. Configure DHCP relay and authorized ARP. # Configure DHCP relay. [Router] dhcp enable [Router] dhcp relay client-information record [Router] interface gigabitethernet 1/0/2 [Router GigabitEthernet1/0/2] ip address [Router GigabitEthernet1/0/2] ip address sub [Router-GigabitEthernet1/0/2] dhcp select relay [Router-GigabitEthernet1/0/2] dhcp relay server-address # Enable authorized ARP. [Router-GigabitEthernet1/0/2] arp authorized enable [Router-GigabitEthernet1/0/2] quit 3. Configure portal authentication: # Configure a portal authentication server. [Router] portal server newpt [Router-portal-server-newpt] ip key simple portal [Router-portal-server-newpt] port [Router-portal-server-newpt] quit # Configure a portal Web server. [Router] portal web-server newpt [Router-portal-websvr-newpt] url 361

378 [Router-portal-websvr-newpt] quit # Enable re-dhcp portal authentication on GigabitEthernet 1/0/2. [Router] interface gigabitethernet 1/0/2 [Router GigabitEthernet1/0/2] portal enable method redhcp # Reference the portal Web server newpt on GigabitEthernet 1/0/2. [Router GigabitEthernet1/0/2] portal apply web-server newpt # Configure the BAS-IP as for portal packets sent from GigabitEthernet 1/0/2 to the portal authentication server. [Router GigabitEthernet1/0/2] portal bas-ip [Router GigabitEthernet1/0/2] quit Verifying the configuration # Verify the portal configuration by executing the display portal interface command. (Details not shown.) # Display information about preauthentication portal users. [Router] display portal user pre-auth interface gigabitethernet 1/0/2 MAC IP VLAN Interface 0015-e9a6-7cfe GigabitEthernet1/0/2 State: Online VPN instance: N/A DHCP IP pool: N/A User profile: N/A Session group profile: N/A ACL: 3010 Inbound CAR: N/A Outbound CAR: N/A Inbound priority: N/A Outbound priority: N/A Example: Configuring direct portal authentication using a local portal Web service Network configuration As shown in Figure 132, the host is directly connected to the router (the access device). The host is assigned a public IP address either manually or through DHCP. The router acts as both a portal authentication server and a portal Web server. A RADIUS server acts as the authentication/accounting server. Configure direct portal authentication on the router. 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 132 Network diagram 362

379 Configuration prerequisites and guidelines Procedure Configure IP addresses for the host, router, and server as shown in Figure 132 and make sure they can reach each other. Configure the RADIUS server correctly to provide authentication and accounting functions. Customize the authentication pages, compress them to a file, and upload the file to the root directory of the storage medium of the router. 1. Configure a RADIUS scheme: # Create a RADIUS scheme named rs1 and enter its view. <Router> system-view [Router] radius scheme rs1 # Specify the primary authentication server and primary accounting server, and configure the keys for communication with the servers. [Router-radius-rs1] primary authentication [Router-radius-rs1] primary accounting [Router-radius-rs1] key authentication simple radius [Router-radius-rs1] key accounting simple radius # Exclude the ISP domain name from the username sent to the RADIUS server. [Router-radius-rs1] user-name-format without-domain [Router-radius-rs1] quit # Enable RADIUS session control. [Router] radius session-control enable 2. Configure an authentication domain: # Create an ISP domain named dm1 and enter its view. [Router] domain dm1 # Configure AAA methods for the ISP domain. [Router-isp-dm1] authentication portal radius-scheme rs1 [Router-isp-dm1] authorization portal radius-scheme rs1 [Router-isp-dm1] accounting portal radius-scheme rs1 [Router-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. [Router] domain default enable dm1 3. Configure portal authentication: # Create a portal Web server named newpt and specify as the URL of the portal Web server. The IP address in the URL must be the IP address of a Layer 3 interface routable to the portal client or a loopback interface (except ) on the device. [Router] portal web-server newpt [Router-portal-websvr-newpt] url [Router-portal-websvr-newpt] quit # Enable direct portal authentication on GigabitEthernet 1/0/2. [Router] interface gigabitethernet 1/0/2 [Router GigabitEthernet1/0/2] portal enable method direct # Specify portal Web server newpt on GigabitEthernet 1/0/2. [Router GigabitEthernet1/0/2] portal apply web-server newpt [Router GigabitEthernet1/0/2] quit 363

380 # Create an HTTP-based local portal Web service and enter its view. [Router] portal local-web-server http # Specify file abc.zip as the default authentication page file for the local portal Web service. (Make sure the file exist under the root directory of the router.) [Router portal-local-websvr-http] default-logon-page abc.zip # Set the HTTP listening port number to 2331 for the local portal Web service. [Router portal-local-webserver-http] tcp-port 2331 [Router portal-local-websvr-http] quit Verifying the configuration # Verify that the portal configuration has taken effect. [Router] display portal interface gigabitethernet 1/0/2 Portal information of GigabitEthernet1/0/2 Authorization Strict checking ACL Disabled User profile Disabled IPv4: Portal status: Enabled Portal authentication method: Direct Portal web server: newpt Authentication domain: Not configured Pre-auth policy: Not configured User-dhcp-only: Disabled Pre-auth IP pool: Not configured Max Portal 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 Authentication domain: Not configured Pre-auth policy: Not configured User-dhcp-only: Disabled Pre-auth IP pool: Not configured Max Portal users: Not configured Bas-ipv6: Not configured User detection: Not configured Action for server detection: Server type Server name Action

381 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 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. [Router] display portal user interface gigabitethernet 1/0/2 Total portal users: 1 Username: abc Portal server: newpt State: Online VPN instance: N/A MAC IP VLAN Interface 0015-e9a6-7cfe GigabitEthernet1/0/2 Authorization information: IP pool: N/A User profile: N/A Session group profile: N/A ACL: N/A Inbound CAR: N/A Outbound CAR: N/A Inbound priority: N/A Outbound priority: N/A Example: Configuring MAC-based quick portal authentication Network configuration As shown in Figure 133, the host accesses the network through a router. The host is assigned a public IP address either manually or through DHCP. A portal server acts as a portal authentication server, a portal Web server, and a MAC binding server. A RADIUS server acts as the authentication/accounting server. Configure direct portal authentication, so the host can access only the portal Web server before passing the authentication and can access other network resources after passing the authentication. 365

382 Figure 133 Network diagram Configuration prerequisites Configure IP addresses for the host, router, and servers as shown in Figure 133 and make sure they can reach each other. Configure the RADIUS server correctly to provide authentication and accounting functions. Configuring the portal server on IMC PLAT 7.1 In this example, the portal server runs on IMC PLAT 7.1(E0303), IMC EIA 7.1(F0303), and IMC EIP 7.1(F0303). 1. Configure the portal authentication 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 134. c. Configure the portal server parameters as needed. This example uses the default values. d. Click OK. Figure 134 Portal authentication server configuration 2. Configure the IP address group: 366

383 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 135. c. Enter the IP group name. d. Enter the start IP address and end IP address of the IP group. Make sure the client 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. Figure 135 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 136. c. Enter the device name. d. Enter the IP address of the router'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 router. g. Select Directly Connected for Access Method. h. Click OK. 367

384 Figure 136 Adding a portal device 4. Associate the portal device with the IP address group: a. As shown in Figure 137, 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 138. 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. Select Supported for Transparent Authentication. f. Use the default settings for other parameters. g. Click OK. Figure 137 Device list 368

385 Figure 138 Adding a port group 5. Select User Access Policy > Service Parameters > Validate System Configuration from the navigation tree to validate the configurations. Configuring the MAC binding server on IMC PLAT 7.1 In this example, the MAC binding server runs on IMC PLAT 7.1(E0303), IMC EIA 7.1(F0303), and IMC EIP 7.1(F0303). 1. Add an access policy: a. Select User Access Policy > Access Policy from the navigation tree to open the access policy page. b. Click Add to open the page as shown in Figure 139. c. Enter the access policy name. d. Select a service group. e. Use the default settings for other parameters. f. Click OK. Figure 139 Adding an access policy 2. Add an access service: 369

386 a. Select User Access Policy > Access Service from the navigation tree to open the access service page. b. Click Add to open the page as shown in Figure 140. c. Enter the service name. d. Select the Transparent Authentication on Portal Endpoints option. e. Use the default settings for other parameters. f. Click OK. Figure 140 Adding an access service 3. Add an access user: a. Select Access User > All Access Users from the navigation tree to open the access user page. b. Click Add to open the page as shown in Figure 141. c. Select an access user. d. Set the password. e. Select a value from the Max. Transparent Portal Bindings list. f. Click OK. Figure 141 Adding an access user 4. Configure system parameters: a. Select User Access Policy > Service Parameters > System Settings from the navigation tree to open the system settings page. b. Click the Configure icon for User Endpoint Settings to open the page as shown in Figure 142. c. Select whether to enable transparent portal authentication on non-smart devices. In this example, select Enable for Non-Terminal Authentication. 370

387 d. Click OK. e. Click the Configure icon for Endpoint Aging Time to open the page as shown in Figure 143. f. Set the endpoint aging time as needed. This example uses the default value. Figure 142 Configuring user endpoint settings Figure 143 Setting the endpoint aging time 5. Select User Access Policy > Service Parameters > Validate System Configuration from the navigation tree to validate the configurations. Configuring the router 1. Configure a RADIUS scheme: # Create a RADIUS scheme named rs1 and enter its view. <Router> system-view [Router] radius scheme rs1 # Specify the primary authentication server and primary accounting server, and configure the keys for communication with the servers. [Router-radius-rs1] primary authentication [Router-radius-rs1] primary accounting [Router-radius-rs1] key authentication simple radius [Router-radius-rs1] key accounting simple radius # Exclude the ISP domain name from the username sent to the RADIUS server. [Router-radius-rs1] user-name-format without-domain [Router-radius-rs1] quit # Enable RADIUS session control. [Router] radius session-control enable 2. Configure an authentication domain: # Create an ISP domain named dm1 and enter its view. [Router] domain dm1 # Configure AAA methods for the ISP domain. [Router-isp-dm1] authentication portal radius-scheme rs1 371