User Connection Management (UCM) is a unified user management component. UCM centralizedly manages connections of various access users to simplify user management and O&M.

Basic UCM functional structure

As shown in Figure 1, the access user login procedure involves five components. UCM is the bridge among the other four components. UCM coordinates the interoperation among these components and assists user connection setup, maintenance, and removal.

Figure 1 Basic UCM functional structure

This chapter describes only the basic functions of these components. For more information, see the documents for these components.

The basic functions of these components are as follows:

· User access identification component—Identifies and processes various access protocol packets of users, and obtains the usernames, passwords, and physical locations of users in the user authentication procedure to provide information and security for valid user access.

· UCM component—Acts as a bridge among the other four components to coordinate the interoperation among these components and assist user connection setup, maintenance, and removal.

· AAA component—Performs authentication, authorization, and accounting for users.

· Address management component—Allocates IP addresses to access users, and ensure proper use of IP resources through unified IP address management.

· Service control component—Controls the access privilege, bandwidth, and QoS policies for the basic services and value-added services of access users.

UCM user types

Depending on application scenarios of users, users managed by UCM include the following types:

· Device management users—Log in to devices and configure and monitor devices. These users can provide FTP, HTTP, HTTPS, and Telnet services.

· Network access users—Access networks through devices and access network resources. These uses can provide IPoE, PPPoE, and L2TP services. Among these services, the IPoE, PPPoE, and L2TP services are uniformly called Broadband Remote Access Server (BRAS) features.

Basic UCM user access procedure

This chapter describes only the basic user access and authentication procedures. For more information, see the documents for related protocol modules.

The basic UCM user access procedure is as follows:

1. The user identification component obtains authentication information.

After the user identification component receives connection requests from a user endpoint, the component obtains the username, password, and physical location from the packets and sends the information to UCM for authentication.

2. UCM requests authentication.

UCM determines whether to allow the user to access based on conditions such as access restrictions. If the user is allowed to access, UCM sends authentication information to the AAA component.

3. AAA authenticates and authorizes the user.

The AAA component authenticates and authorizes the user according to the AAA scheme and returns the authentication result and authorization information to UCM.

4. UCM requests IP address allocation.

If the user successfully passes authentication, UCM requests IP addresses from the address management component.

5. The address management component allocates IP addresses.

According to the user information, the address management component allocates IP addresses and returns the allocation result to UCM. To allocate remote IP addresses, the address management component must connect to an external DHCP server.

6. UCM allows the user to come online.

UCM returns the authentication result and the allocated IP addresses to the access identification component. The access identification allows the user to come online.

7. The AAA component and the service control component perform accounting and control.

After the user comes online, the AAA component and the service control component together control accounting, bandwidth limit, and QoS for basic services and value-added services of the user.

CUPS in UCM

About this task

On a traditional BRAS, the control plane capabilities might not match the forwarding plane capabilities, the resources cannot be shared, and new services cannot be deployed in time. The vBRAS CP and UP separation (CUPS) solution is introduced to solve this problem.

In this solution, the forwarding plane and control plane are completely decoupled and are independent of each other. The solution contains control plane (CP) roles and user plane (UP) roles, which together implement the BRAS functionality.

· CP—Performs control plane services, including user identification and address allocation and management. Typically, a CP is a vBRAS.

· UP—Performs the forwarding plane services, including data packet forwarding and traffic control. A UP can be a router, or vBRAS.

The following three channels are established between the CP and UP to implement CUPS.

· Management channel—Deploys configuration between the CP and UP.

· Control channel—Deploys entries between the CP and UP.

· Protocol tunnel—Transmits protocol packets between the CP and UP.

BRAS operating modes

In a CUPS network, a BRAS can operate in one of the following modes:

· Common mode—A BRAS operating in this mode performs both control and forwarding services. A device operating in this mode is called a unified device.

· Control plane mode—Also known as the session mode. This mode implements the CP function based on remote interfaces. When the UP connected to a CP supports IPoE, PPPoE, or L2TP, you can configure the session mode. In this mode, the CP sends BRAS sessions to the UP. The UP performs data packet forwarding according to the received sessions. For more information about remote interfaces, see CP-UP connection management in the vBRAS-CP configuration guides.

· User plane mode—A BRAS operating in this mode performs only the forwarding service. A BRAS operating in user plane mode is a UP.

The control plane mode and user plane mode are collectively referred to as the CUPS mode.

NOTE:

· Only BRAS features IPoE, PPPoE, and L2TP support CUPS. For more information about IPoE, PPPoE, and L2TP, see BRAS Services Configuration Guide.

· Unless otherwise specified, a BRAS in this document operates in common mode.

Restrictions and guidelines: UCM configuration

Telnet users that do not use AAA authentication are not managed by UCM.

On an interface with online UCM users, you cannot configure any of the following features:

· Binding an IRF port to an IRF physical interface (port group interface). For more information, see IRF configuration in Virtual Technologies Configuration Guide.

· Switching the link mode of an interface (port link-mode). For more information, see Ethernet interface configuration in Interface Configuration Guide.

· Configuring an interface as a reflector port for a remote source mirroring group (mirroring-group reflect-port). For more information, see mirroring configuration in Network Management and Monitoring Configuration Guide.

· Assigning an interface to an aggregation group (port link-aggregation group). For more information, see Ethernet link aggregation configuration in Layer 2—LAN Switching Configuration Guide.

UCM tasks at a glance

To configure UCM, perform the following tasks:

1. Configuring the CUPS mode

¡ Configuring the operating mode of a UP

2. Configuring features specific to BRAS access users

¡ Configuring the interface-down policy for online BRAS users on an interface

¡ Configuring the maximum number of access users allowed on an interface

¡ Setting the traffic accounting frequency mode for online BRAS users

¡ Configuring flow rate calculation for online users on the BRAS

¡ Enabling logging for access users

¡ Setting the online access user session count alarm thresholds on the device

¡ Configuring the per-slot user count trap feature

¡ Configuring the user online failure threshold alarm function

¡ Configuring the packet loss ratio alarm for access user detection packets‌

¡ Configuring auto user logout before BRAS reboot

¡ Configuring the data backup mode for the BRAS service module

¡ Configuring the NAS-Port-Type attribute for an interface

¡ Configuring the device to use four-dimensional interfaces to communicate with AAA servers

¡ Configure the escape rules for parameters in the web server URL redirected by the device to users‌

¡ Configuring a BRAS to send accounting-update messages to notify the AAA server of the user NAT information changes

¡ Configuring the BRAS not to carry attribute 97 when sending authentication and accounting packets to the AAA server

¡ Manually changing the binding between the load-sharing user group and NAT instance for an access user

¡ Configuring BRAS device compatibility with old-style commands‌

¡ Configuring the feature of retaining UNR host routes of users when an interface switches to backup

¡ Configuring the parameters for sending gratuitous ARP packets upon the master/backup UP switchover (on UPs)

3. Configuring CPU usage-based dynamic resource management

¡ Enabling the CPU usage awareness feature on the device

¡ Enabling the device to adjust the user detection frequency based on CPU usage

¡ Enabling the device to adjust the real-time accounting packet sending frequency based on CPU usage

¡ Enabling the device to adjust the online user traffic statistics collection frequency based on CPU usage

¡ Configuring the maximum number of concurrent online users allowed on the device and the threshold for recovering user access

¡ Configuring the access user authentication rate

¡ Configure the user access rates at different CPU usage levels on the device

¡ Enabling the CPU usage alarm logs on the device

4. Configuring access user common management

¡ Configuring service tracing objects

Prerequisites

UCM simplifies user management through coordinating the interoperation among AAA and address management components and assisting user connection setup, maintenance, and removal. For UCM and the other components to cooperate, complete the following tasks before configuring UCM:

· To configure DHCP packet initiation, you must first install and configure DHCP servers. If this network is a DHCP relay agent network, you must enable the DHCP relay agent on the BRAS.

· To perform authentication through a remote RADIUS server, perform the following tasks:

a. Make sure the RADIUS server is successfully installed.

b. Configured and configure the corresponding usernames and passwords on the RADIUS server.

c. Configure the RADIUS client on the BRAS.

· To perform security check and authorization through a remote security server, perform the following tasks:

d. Configure the security policies on the H3C IMC security policy server.

e. Specify the security policy server IP address on the BRAS.

For more information about configuring the RADIUS client and configuring the security policy server, see AAA configuration in BRAS Services Configuration Guide.

· To perform authentication through the local device, you must configure related local users and their attributes on the BRAS. For information about configuring local users, see AAA configuration in BRAS Services Configuration Guide.

· Make sure users, the BRAS, and servers can reach each other through routes.

· To configure a CUPS network, first plan which devices are UPs and which devices are CPs.

Configuring the CUPS mode

This chapter describes only the basic configuration of the CUPS mode. For information about configuring the BRAS features in CUPS mode, see documents for related BRAS features.

In CUPS mode, the device can act only as a UP and cannot act as a CP.

This section describes only basic settings when the device acts as a UP. For CP-related settings, see the documents for the device acting as a CP.

Configuring the operating mode of a UP

About this task

In a CUPS mode, when a UP is connected to a CP in session mode, perform this task to configure the device to operate in user plane mode.

Restrictions and guidelines

The user plane mode requires port 1701. If the port is used by another service on the device, you cannot set the user plane mode.

Procedure

1. Enter system view.

system-view

2. Configure the device to operate in user plane mode.

work-mode user-plane

By default, a BRAS operates in common mode.

Configuring features specific to BRAS access users

Configuring the interface-down policy for online BRAS users on an interface

About this task

By default, when an interface goes down, the users are forced to go offline. When the interface recovers from down to up, these users must perform authentication again to come online. To prevent users from frequently coming online and going offline because the interface frequently comes up and goes down, you can use this feature to keep users online after the interface goes down.

Restrictions and guidelines

This feature takes effect only on PPPoE and IPoE access users.

Procedure

1. Enter system view.

system-view

2. Enter interface view.

interface interface-type interface-number

3. Configuring the interface-down policy for online BRAS users on an interface

user-policy interface-down online [ no-user-detect ]

By default, BRAS users on an interface are forced to go offline after the interface goes down.

When you configure an interface to keep the users online after the interface goes down, to prevent users from being logged out because the users fail online detection during the period the interface recovers from down to up, specify the no-user-detect keyword.

Configuring the maximum number of access users allowed on an interface

Restrictions and guidelines

In a CUPS network, this feature takes effect only when it is configured on CPs.

If the configured limit is smaller than the number of existing users on an interface (or VLANs on an interface), the configuration succeeds and the existing users are not affected. However, new users cannot access on the interface (or VLANs on the interface).

When this command is executed together with the pppoe-server session-limit per-vlan command and the access-limit command in an ISP domain, the three commands all take effect. The three commands control the number of users on the interface (or VLANs on the interface) in different perspectives, and the number of users is controlled by all the three commands. A new PPPoE user can access only when none of these limits is reached.

When this command is executed together with the access-limit command in an ISP domain, the two commands both take effect. The two commands control the number of BRAS users on the interface (or VLANs on the interface) in different perspectives, and the number of BRAS users is controlled by both commands. A new BRAS user can access only when neither limit is reached.

Procedure

1. Enter system view.

system-view

2. Enter interface view.

interface interface-type interface-number

3. Configure the maximum number of access users allowed on the interface.

access-limit user-number [ start-vlan start-vlan [ end-vlan end-vlan ] [ qinq qinq-vlan ] ]

By default, the maximum number of access users on an interface is not limited.

Setting the traffic accounting frequency mode for online BRAS users

About this task

Perform this task to adjust the frequency at which the device updates the online BRAS user statistics as needed. The following traffic accounting frequency modes are supported:

· fast—Fast mode. For high accuracy of the BRAS user traffic statistics, specify this keyword.

· normal—Normal mode. For medium accuracy of the BRAS user traffic statistics, specify this keyword.

· slow—Slow mode. For low accuracy of the BRAS user traffic statistics, specify this keyword.

Restrictions and guidelines

In a CUPS network, this feature takes effect only when it is configured on CPs.

Procedure

Table 1 ‍Enter system view.

system-view

2. Set the traffic accounting frequency mode for online BRAS users.

flow-statistics frequency { fast | normal | slow }

By default, the traffic accounting frequency mode for online BRAS users is normal.

Configuring flow rate calculation for online users on the BRAS

About this task

In the live network, you can allocate bandwidth to different users based on their actual requirements to make efficient use of bandwidth resources. To quickly locate users with abnormal bandwidth (such as users with significantly lower or higher Internet access speeds than their allocated bandwidth), you can enable flow rate calculation for online users. With this feature enabled, you can execute the display access-user command with the flow-rate keyword specified to view information of users whose flow rates fall within the specified range.

After flow rate calculation for online users is enabled, the device will calculate the flow rate for each online user based on the interval value (5 by default) specified in the access-user flow-rate-calculate enable command and the online user traffic accounting frequency mode (normal mode by default) configured by using the flow-statistics frequency command according to certain principles.

Restrictions and guidelines

In the live network, configure this feature according to the total number of users on the device and the frequency mode set by using the flow-statistics frequency command. For more information, see the following table. For example, when the total number of users on the device is less than 50000 and the frequency mode is fast, configure the interval for calculating user flow rates to be equal to or greater than 3 minutes as a best practice.

Table 2 Recommended intervals for calculating the user flow rates

Frequency mode (right)	Fast mode (fast )	Normal mode (normal)	Slow mode (sflow)
Total number of users (below)	Fast mode (fast )	Normal mode (normal)	Slow mode (sflow)
Less than 50000	≥3 minutes	≥6 minutes	≥12 minutes
50000 to 120000	≥7 minutes	≥14 minutes	≥28 minutes
120000 to 250000	≥15 minutes	≥30 minutes	≥60 minutes
250000 to 500000	≥30 minutes	≥60 minutes	≥120 minutes
500000 to 1000000	≥60 minutes	≥120 minutes	≥240 minutes
More than 1000000	≥100 minutes	≥200 minutes	≥400 minutes

Enabling this feature will occupy a certain amount of memory resources. To avoid occupying too many memory resources, enable flow rate calculation for online users only when you need to obtain user rate information. Promptly disable this feature when you do not need to obtain user rate information.

If a user has no service traffic within a certain interval, the device will not use the configured interval as the interval for calculating the user flow rates. Instead, the device will automatically calculate the interval for the user flow rates based on the actual user traffic conditions. To view the interval for automatically calculating the user flow rates and the statistics of the user flow rates within that interval, execute the display access-user verbose command.

Procedure

1. Enter system view.

system-view

2. Enable flow rate calculation for online users.

access-user flow-rate-calculate enable [ interval interval ]

By default, flow rate calculation for online users is disabled.

Enabling logging for access users

About this task

To meet the maintenance requirements of network administrators, this feature enables the device to generate logs and send them to the information center. Logs are generated after a user comes online successfully, fails to come online, normally goes offline, or abnormally goes offline. A log entry contains information such as the username, IP address, interface name, inner VLAN, outer VLAN, MAC address, and failure causes. For information about the log destination and output rule configuration in the information center, see Network Management and Monitoring Configuration Guide.

Restrictions and guidelines

As a best practice, disable this feature to prevent excessive log output.

In a CUPS network, this feature takes effect only when it is configured on CPs.

Procedure

1. Enter system view.

system-view

2. Enable logging for access users.

access-user log enable [ abnormal-logout | failed-login | normal-logout | successful-login ] *

By default, logging for BRAS access users is disabled.

Setting the online access user session count alarm thresholds on the device

About this task

(In standalone mode.) The online access user session count on the device is the total number of online IPoE sessions, PPPoE sessions, and L2TP sessions on the device.

(In IRF mode.) The online access user session count on the device is the total number of online IPoE sessions, PPPoE sessions, and L2TP sessions on the IRF system.

You can use this feature to set the upper alarm threshold and lower alarm threshold for the online access user session count. When the online access user session count exceeds the upper alarm threshold or drops below the lower threshold, an alarm is triggered automatically. Then, the administrator can promptly know the online user conditions of the network. To view the total number of access users, use the display access-user command.

The user session count alarm function counts only user sessions that occupy session resources. In the current software version, only the following sessions occupy session resources:

· The following IPoE sessions:

¡ Sessions of individual access users

¡ Sessions of interface-leased users

¡ Sessions of interface-leased subusers

¡ Sessions of subnet-leased users

¡ Sessions of subnet-leased subusers

¡ Sessions of L2VPN-leased users

· PPPoE sessions

· L2TP sessions

Either a single-stack user or dual-stack user occupies one session resource.

Suppose the maximum number of online access user sessions allowed on the device is a, the upper alarm threshold is b, and the lower alarm threshold is c. The following rules apply:

· When the online access user session count exceeds a×b or drops below a×c, the corresponding alarm information is output.

· When the online access user session count returns between the upper alarm threshold and lower alarm threshold, the alarm clearing information is output.

In some special cases, the online access user session count frequently changes in the critical range, which causes frequent output of alarm information and alarm clearing information. To avoid this problem, the system introduces a buffer area when the online access user session count recovers from the upper or lower threshold. The buffer area size is 10% of the difference between the upper threshold and the lower threshold. Suppose the buffer area size is d. Then, d=a×(b-c)÷10. When the online access user session count drops below a×b-d or exceeds a×c+d, the alarm information is output.

For example, suppose a is 1000, b is 80%, and c is 20%. Then, d= a×(b-c)÷10=1000×(80%-20%)÷10=1000×60%÷10=600÷10=60.

· When the online access user session count exceeds the upper threshold a×b=1000×80%=800, the upper threshold alarm is output. When the online access user session count restores to be smaller than a×b-d=800-60=740, the alarm clearing information is output.

· When the online access user session count drops below the lower threshold a×c=1000×20%=200, the lower threshold alarm is output. When the online access user session count restores to be greater than a×c+d=200+60=260, the alarm clearing information is output.

The upper threshold alarm information output and the alarm clearing information output both contain logs and traps.

· The generated log messages by the device will be sent to the information center. The information center configuration specifies the log message sending rule and destination. For more information about the information center, see Network Management and Monitoring Configuration Guide.

· For traps to be correctly sent to the NMS host, you must execute the snmp-agent trap enable user-warning-threshold command in addition to configuring the SNMP alarm feature correctly. For more information about SNMP alarms, see SNMP configuration in Network Management and Monitoring Guide.

Restrictions and guidelines

The upper alarm threshold must be greater than the lower alarm threshold.

Procedure

1. Enter system view.

system-view

2. Configure the upper and lower online access user session count alarm thresholds.

access-user session-threshold { lower-limit lower-limit-value | upper-limit upper-limit-value }

By default, the upper online access user session count alarm threshold is 100, and the lower online access user session count alarm threshold is 0.

3. Enable the device-level user count trap feature.

snmp-agent trap enable user-warning-threshold

By default, the device-level user count trap feature is disabled.

Configuring the per-slot user count trap feature

About this task

You can use this feature to set the per-slot user count alarm threshold. When the user count on a slot exceeds the threshold, an alarm is triggered automatically. Then, the administrator can promptly know the online user conditions of the network.

This feature counts only the number of IPoE users, PPPoE users, and L2TP users.

· A dual-stack PPPoE user is counted as one user.

· A dual-stack IPoE user is counted as one user.

· For IPoE leased users, one interface-leased user is counted as one user, and one subnet-leased user is counted as one user.

· For IPoE leased subusers, one subuser is counted as one user.

· The L2TP users on LACs are counted in the same way PPPoE users are counted. The L2TP users on LNSs are not counted.‌

Suppose the per-slot maximum user count allowed is a and the per-slot user count alarm threshold is b. The following rules apply:

· When the user count on a slot exceeds a×b, the alarm information is output.

· When the user count on a slot drops within the normal range, the alarm clearing information is output.

In some special cases, the user count on a slot frequently changes in the critical range, which causes frequent output of alarm information and alarm clearing information. To avoid this problem, the system introduces a buffer area when the user count on a slot drops below the threshold. The buffer area size is 10% of the threshold set. Suppose the buffer area size is c. Then, c=a×b÷10. When the user count on a slot drops below a×b-c, the alarm clearing information is output.

For example, suppose a is 1000 and b is 80%. Then, c= a×b÷10=1000×80%÷10=80.

· When the user count on a slot exceeds a×b=1000×80%=800, the alarm information is output.

· When the user count on a slot drops below a×b-c=800-80=720, the alarm clearing information is output.

The upper threshold alarm information output and the alarm clearing information output both contain logs and traps.

· For traps to be correctly sent to the NMS host, you must execute the snmp-agent trap enable slot-user-warning-threshold command in addition to configuring the SNMP alarm feature correctly. For more information about SNMP alarms, see SNMP configuration in Network Management and Monitoring Guide.

Setting the per-slot user count alarm threshold

1. Enter system view.

system-view

2. Set the per-slot user count alarm threshold.

slot-user-warning-threshold threshold-value

By default, the per-slot user count alarm threshold is 100.

3. Enable the per-slot user count trap feature.

snmp-agent trap enable slot-user-warning-threshold

By default, the per-slot user count trap feature is disabled.

Configuring the user online failure threshold alarm function

About this task

With the user online failure threshold alarm function enabled, when the number of user online failures within an alarm detection interval exceeds the specified threshold, an alarm is automatically triggered. Then, the administrator can promptly learn the user online failure conditions on the live network. An administrator can execute the display aaa online-fail-record command to view user online failure records.

The alarm information output contains logs and traps.

· To send the traps to an NMS correctly, you must also configure SNMP correctly as described in Network Management and Monitoring Configuration Guide. For more information about SNMP alarms, see SNMP configuration in Network Management and Monitoring Guide.

In standalone mode:

The total number of access user online failures refers to the sum of IPoE user, PPPoE user, and L2TP user online failures on the whole device.

The total number of access user online events refers to the sum of IPoE user, PPPoE user, and L2TP user online failures and online successes on the whole device.

In IRF mode:

The total number of access user online failures refers to the sum of IPoE user, PPPoE user, and L2TP user online failures on the whole IRF system.

The total number of access user online events refers to the sum of IPoE user, PPPoE user, and L2TP user online failures and online successes on the whole IRF system.

If a single user comes online successfully or fails to come online for multiple times, each online success or failure is counted in the total number of online successes or failure.

When the device calculates the number of online events of a user, the device uniquely identifies a user by the MAC address, inner VLAN, and outer VLAN.

· For a dual-stack user, only if the user successfully comes online in one protocol stack, the user is considered as coming online successfully. A dual-stack user is considered failing to come online only when the user fails to come online in both protocol stacks.

· For an IPoE leased user, the online events of the main user and the online events of the subusers are separately counted.

Procedure

1. Enter system view.

system-view

2. Enable the user online failure threshold alarm function.

access-user online-fail-warning threshold threshold-value period period-value

By default, the user online failure threshold alarm function is disabled.

Configuring the packet loss ratio alarm for access user detection packets‌

About this task

After the online user detection feature is enabled, the device will automatically create a 30-second timer. The timer will be reset after expiration. After the packet loss ratio alarm is enabled for access user detection packets, an alarm will be automatically triggered in either of the following conditions:

· The packet loss ratio calculated exceeds the specified alarm threshold when the 30-second timer expires continuously for three times, and the number of packets sent within each 30-second timer exceeds 50.

· The packet loss ratio calculated within the last 30 seconds when the 30-second timer expires restores to the normal range (equal to or less than the specified alarm threshold) after an alarm is output.

In this way, the administrator can timely learn the packet loss conditions of user detection packets on the live network.

In this function, the packet loss ratio of detection packets refers to the ratio of dropped packets (sent packets - received packets) to all detection packets within the 30-second timer on a detected interface. The formula is as follows: the packet loss ratio = (sent packets - received packet)/sent packets. If you execute the display access-user user-detect packet-loss-ratio or display ppp keepalive packet-loss-ratio command at a time point within a 30-second timer, this command displays the packet loss ratio statistics collected at the specified time point within the 30-second timer. For example, if you execute this display command at the 10th second within a 30-second timer, this command displays the packet loss ratio statistics collected within the 10 seconds.

The alarm information output contains only logs. The generated log messages by the device will be sent to the information center. The information center configuration specifies the log message sending rule and destination. For more information about the information center, see Network Management and Monitoring Configuration Guide.

Restrictions and guidelines

On a CUPS network, detection packets are sent and received on UPs. Therefore, this command takes effect only when it is executed on UPs. L2TP users do not have interface information on UPs. Therefore, the packet loss ratio statistics for L2TP users are collected on a per-slot basis.‌

This feature applies to only IPoE users, PPPoE users, and L2TP users.

Procedure

1. Enter system view.

system-view

2. Enable the packet loss ratio alarm for access user detection packets.

access-user user-detect packet-loss-ratio-threshold threshold-value

By default, the packet loss ratio alarm is disabled for user detection packets.

Configuring auto user logout before BRAS reboot

About this task

By default, if devices are rebooted as planned or slots are separately rebooted when devices are upgraded, the devices or slots will not actively send accounting stop packets to the AAA server during the reboot process. During the reboot process, the devices will log out users, but the AAA server cannot sense the logout events and still considers the users online. Within a short period of time after the devices or slots are rebooted, the online users before reboot cannot log in again because the AAA server still considers them as online.

To resolve this issue, enable the feature of auto user logout before BRAS reboot. With this feature enabled, when the reboot command is executed each time to reboot a device or slot, the device first forbids new users from coming online, and logs out all online users or online users on the slot to be rebooted. When users are logged out, the device will actively send accounting stop packets to the AAA server. After these users are logged out, the device or slot will be rebooted.

Restrictions and guidelines

When a slot is restarted, this feature takes effect only on users coming online through physical interfaces in the slot.

If you execute the reboot command with the force keyword specified, the feature of auto user logout before BRAS reboot does not take effect.

On a CUPS network, this feature takes effect only when it is configured on CPs.‌

Procedure

1. Enter system view.

system-view

2. Enable auto user logout before BRAS reboot.

bras auto-cut-user before-reboot

By default, the feature of auto user logout before BRAS reboot is disabled.

Configuring the data backup mode for the BRAS service module

About this task

In non-realtime mode, the BRAS service module does not back up the running data to the LMDB in real time and the following rules apply:

· To avoid data loss when the BRAS service module process is normally restarted (for example, by using the process restart command), the BRAS service module will back up the running data of the module to the LMDB before the process is restarted. The LMDB is shipped with the device for storing important information such as backup module running data.

· When the BRAS service module process on the active MPU is abnormal, the data of the BRAS service module on the current active MPU will be lost. The device determines whether to forcibly reboot the active MPU according to whether the auto-reboot-board keyword is specified. (In standalone mode.)

· When the BRAS service module process on the global active MPU is abnormal, the data of the BRAS service module on the current global active MPU will be lost. The device determines whether to forcibly reboot the global active MPU according to whether the auto-reboot-board keyword is specified. (In IRF mode.)

In realtime mode, the BRAS service module will back up the running data to the LMDB in real time to avoid data loss. For traffic data in the UCM module, if user traffic changes, the backup user information in the LMDB will be frequently updated, which will increase the processing load of the LMDB. To avoid this issue, the system triggers backup user information updates in the LMDB according to the following principles:‌

· If the traffic of a user does not change within 5 minutes or the traffic change of a user reaches the update threshold 50 MB, UCM will back up information of the user again to the LMDB to update backup information of the user in the LMDB.

· If the traffic of a user does not change within 5 minutes, UCM does not update the backup information of the user in the LMDB.

Restrictions and guidelines

Active/standby MPU switchover is automatically performed only when the auto-reboot-board keyword is specified in the dual-MPU environment and the BRAS service module process is abnormal.

In the current software version, this feature takes effect only on the UCM, PPP, and DHCP modules.

When you execute this command, follow these restrictions and guidelines:

· As a best practice to ensure device performance when a large number of users are online, do not frequently execute this command to switch the data backup mode for the BRAS service module.

· When you switch the backup mode from non-realtime to realtime, the device will immediately back up the running data of the BRAS service module to the LMDB. Then, the data will be updated in real time.

· When you switch the data backup mode from realtime to non-realtime, the device will delete the data that has been backed up to the LMDB for the BRAS service module. Then, the device will process the data according to whether the auto-reboot-board keyword is specified.

On a CUPS network, the command executed on a CP takes effect only on the CP, the command executed on a UP takes effect only on the UP, and they do not affect each other. Execute this command on a CP or UP as needed.‌

Procedure

1. Enter system view.

system-view

2. Configure the data backup mode for the BRAS service module.

bras data-backup-mode { non-realtime [ auto-reboot-board ] | realtime }

By default, the data backup mode is realtime for the BRAS service module.

Configuring the NAS-Port-Type attribute for an interface

About this task

The NAS-Port-Type attribute is used for RADIUS authentication and accounting. For information about the NAS-Port-Type attribute, see RFC 2865.

Restrictions and guidelines

This feature does not affect existing users.

‌If you do not execute the bras compatible old-style-commands enable command to enable BRAS device compatibility with old-style commands, the nas-port-type command has no configuration restrictions.

‌After you execute the nas-port-type command, it does not affect enabling or disabling BRAS device compatibility with old-style commands unless you specify the cable keyword.

‌After you execute the nas-port-type cable command, you cannot enable BRAS device compatibility with old-style commands.

‌After you execute the bras compatible old-style-commands enable command to enable BRAS device compatibility with old-style commands, follow these restrictions:

· You can use only the old-style ip subscriber nas-port-type cable command to set the Cable port type for an interface. To use the new-style nas-port-type cable command to set the Cable port type for an interface, first execute the undo bras compatible old-style-commands enable command to disable BRAS device compatibility with old-style commands, and then execute the nas-port-type cable command.

· To set a port type other than the Cable port type, you can use the new-style nas-port-type command. If you execute the nas-port-type (except with the cable keyword) and ip subscriber nas-port-type cable commands multiple times, the most recent configuration takes effect.

Procedure

1. ‍Enter system view.

system-view

2. Enter interface view.

interface interface-type interface-number

3. Configure the NAS-Port-Type attribute.

nas-port-type { 802.11 | adsl-cap | adsl-dmt | async | cable | ethernet | g.3-fax | hdlc | idsl | isdn-async-v110 | isdn-async-v120 | isdn-sync | piafs | sdsl | sync | virtual | wireless-other | x.25 | x.75 | xdsl }

By default, the NAS-Port-Type attribute of an interface is Ethernet.

Configuring the device to use four-dimensional interfaces to communicate with AAA servers

About this task

In a CUPS network, you need to configure this feature only on the CP and do not need to configure this feature on UPs. More specifically, the remote interface number on the CP is in the format of UP ID/actual interface number on the UP. For example, Remote-XGE 1024/3/1/2, where 1024 is the UP ID and 3/1/2 is a three-dimensional interface number. By default, when the CP communicates with AAA servers, the device uses three-dimensional interface numbers in interface information, for example, NAS-Port-ID. When you need to specify the access UP of a user on the AAA server, use this command to configure the device to use four-dimensional interfaces to communicate with AAA servers. After you execute this command, one dimension of UP ID is added to the original three-dimension interface numbers of the CP, and the interface number format is up-id/original three-dimensional interface number.

By default, in a unified network, when the device communicates with AAA servers, the device uses three-dimensional interface numbers without the chassis information in interface information, for example, NAS-Port-ID. On an IRF fabric, when you need to specify the access IRF member device of a user on the AAA server, use this command to configure the device to use four-dimensional interfaces to communicate with AAA servers.

Restrictions and guidelines

This command takes effect only on users coming online after this command is executed.

On a unified network, this feature takes effect only on users coming online through physical interfaces, and does not take effect on users coming online through global interfaces such as Layer 3 aggregate interfaces. ‌

Procedure

1. Enter system view.

system-view

2. Configure the device to use four-dimensional interfaces to communicate with AAA servers.

access-user four-dimension-mode enable

By default, the device uses three-dimensional interfaces to communicate with AAA servers.

Configure the escape rules for parameters in the web server URL redirected by the device to users‌

About this task

Application scenarios

In scenarios using URL redirection, such as web authentication or ad pushing, if URL parameters with special characters are not properly escaped, browsers might fail to recognize them, leading to webpage display issues. To resolve the issue, you can configure the escape rules for characters in the URL parameters. This ensures that the redirect URL generated by the device is correctly translated in different browsers.

Operating mechanism

In a URL, question marks (?) are used to separate the path and parameter sections. For example, in an IPoE web authentication network, the URL path is configured by using the web-server { ip | ipv6 } command, and the URL parameters are configured by using the web-server url-parameter command.

With escape rules configured, the system translates characters in the URL parameters (after the question mark) as instructed by the escape rules.

During the escaping process, the system does not differentiate between parameter fields but escapes all matching characters in the entire parameter section. The principle of escaping is to replace matching characters with a percent sign (%) followed by the hex ASCII code of that character. For example, to escape ASCII characters A, B, and C in URL parameters, execute access-user url character-transfer user-defined-characters 41 42 43, where 41, 42, and 43 represent the hex codes of characters A, B, and C, respectively. This guides the system to escape the characters to %41, %42, %43, ensuring proper URL translation in all browsers. Other characters will not be escaped.

Restrictions and guidelines

· Before configuring the escape rules for URL parameters, make sure that all the browsers used in the network support the escape result. Support for escape characters might differ by browser, which might affect the display and functions of URL redirection.

· You can use the access-user url character-transfer user-defined-characters command to configure up to 145 custom escape rules.

¡ You can execute this command once to specify up to 145 characters to be escaped, or

¡ execute this command multiple times to specify up to 145 characters.

· As a best practice, do not execute the access-user url character-transfer or undo access-user url character-transfer command when online users are present. If you do so, online users might fail to process URLs based on the rule changes, causing the web authentication page to fail to be displayed properly. If configuration changes are required when users are online, modify the configuration during periods with fewer users to minimize impact. After you change the escape rules, if the web authentication page cannot open for an online user, make the user go offline and then come online again.

Procedure

1. Enter system view.

system-view

2. Configure the escape rules for parameters in the web server URL redirected by the device to users.

access-user url character-transfer { none | reserve | unsafe | user-defined-characters character }

See the command reference for the default setting of the command.

Configuring a BRAS to send accounting-update messages to notify the AAA server of the user NAT information changes

About this task

Application scenarios

To meet the NAT source tracking requirements in the NAT-BRAS collaboration scenario, when the NAT information (including only the public network IP address and port blocks, and excluding extended port blocks) of an access user changes (for example, because the CGN card fails), the BRAS will first send a stop-accounting message and then send a start-accounting message to notify the AAA server of the user information change by default. Then, the AAA server can timely record and refresh the user information. For the BRAS to directly send an accounting-update message to notify the AAA server of the user information change when the NAT information of a user changes, you can configure this feature.

Operating mechanism

With this feature enabled, when the NAT information (including only the public network IP address and port blocks, and excluding incremental port blocks) of a user changes, the BRAS directly sends an accounting-update message to notify the AAA server of the user information change. The sent accounting-update message carries the H3C private attribute H3C-Nat-Port-Range-Update with value 3, which represents the public network IP address and port block change.

Restrictions and guidelines

Before configuring this feature, make sure the BRAS and the connected AAA server can recognize the support the H3C private attribute H3C-Nat-Port-Range-Update. If you cannot do that, use the default settings.

To configure this feature on a CUPS network, execute this command on a CP.‌

Procedure

1. Enter system view.

system-view

2. Configure the BRAS to send an accounting-update message to the AAA server when the NAT information of an access user changes.

access-user nat-info-change send-accounting-update

By default, when the NAT information of an access user changes, the BRAS first sends a stop-accounting message and then a start-accounting message to the AAA server.

Configuring the BRAS not to carry attribute 97 when sending authentication and accounting packets to the AAA server

About this task

Application scenarios

Attribute 97 (Framed-IPv6-Prefix) indicates the user's IPv6 prefix information, with a prefix length of 64 bits.

By default, in the IPv6 scenario, the BRAS will fill in the first 64 bits of a user IPv6 address as a prefix in attribute 97 when sending authentication and accounting packets to the AAA server. This facilitates the AAA server to manage and control the user IPv6 addresses. However, for certain ISPs or application scenarios, providing IPv6 prefix information in non-ND user scenarios might not be necessary or secure. In this case, you can use the access-user authen-and-accounting without-ipv6-prefix command to disable carrying attribute 97.

Operating mechanism

After the access-user authen-and-accounting without-ipv6-prefix command is executed, the BRAS no longer carries attribute 97 when sending authentication and accounting packets to the AAA server. This command effectively prevents the transmission of IPv6 prefix information, reduces the risk of user information leakage, enhances network security, and protects user privacy.

Restrictions and guidelines

· This feature is only applicable to non-ND user scenarios. For example, IPoE unclassified-IPv6 users, DHCPv6 users, and static users.

· For ND user scenarios (such as ND prefix sharing scenarios or one ND prefix per user scenarios), the BRAS will always carry attribute 97 when sending authentication and accounting packets to the AAA server, and cannot be configured to not carry attribute 97 through this command.

· If the AAA server needs to obtain the IPv6 prefix information of the user devices, prohibiting the sending of attribute 97 might cause AAA authentication failure or accounting errors. Configure this feature as needed.

Procedure

1. Enter system view.

system-view

2. Configure the BRAS not to carry attribute 97 when sending authentication and accounting packets to the AAA server.

access-user authen-and-accounting without-ipv6-prefix

By default, the BRAS carries attribute 97 when sending authentication and accounting packets to the AAA server.

Manually changing the binding between the load-sharing user group and NAT instance for an access user

About this task

Application scenarios

In the scenario where global NAT is used to collaborate with BRASs, when the user traffic cannot be forwarded, you can execute this command to manually switch the user to another CGN card that is operating normally. Then, you can identify whether the original CGN card hosting the current user fails.

· If user traffic can be normally forwarded after the switchover, the original CGN card might fail. In this case, identify whether the original CGN card fails.

· If user traffic cannot be forwarded after the switchover, the NAT configuration might have errors. In this case, identify whether the NAT configuration is correct.

Operating mechanism

When you execute this command, the BRAS will re-allocate the public network IP address and port block to the user according to the binding between the load-sharing user group and NAT instance specified in this command, and refresh the user session information. The whole process is automatically done by the device. During the process, the user online state is not affected, and the user stays online.

You can use the display access-user command to view the user-id information and public network IP address information of an access user.

Restrictions and guidelines

Before executing this command, make sure the following conditions are met:

· The NAT instance and user group specified in this command have been bound by using the user-group bind nat-instance command in user authentication domain view. If not, the command will fail to be executed.

· The NAT instance specified in this command is available, for example, the NAT instance-related configuration is correct, the CGN card is in place, and IP addresses and port block resources are available. If not, executing this command might cause the user to go offline.

This command takes effect only once and is not saved in the configuration file. After you execute this command, the user might go offline and then come online. If you still want to change the binding between the load-sharing user group and NAT instance for the access user after the user comes online, execute this command again.

On a CUPS network, to manually change the binding between the load-sharing user group and NAT instance for an access user, you must execute this command on a CP.‌

Procedure

1. Enter system view.

system-view

2. Manually change the binding between the load-sharing user group and NAT instance for an access user.

access-user change user-id user-id nat-instance nat-instance-name user-group user-group-name

Configuring BRAS device compatibility with old-style commands‌

About this task

A software upgrade might change the command style on the BRAS device. To manage the BRAS device without upgrading its NMS software, enable BRAS device compatibility with old-style commands.

BRAS device compatibility with old-style commands enables the device to recognize old-style commands.

Restrictions and guidelines

· Enable this feature only when the NMS software does not recognize the new-style commands and you want to use old-style commands for BRAS device management.

· The following are the old-style commands:

¡ ip subscriber nas-port-type cable

¡ dhcp server ip-pool

¡ ipv6 dhcp pool

¡ dhcp pool-group

¡ ipv6 dhcp pool-group

· The following are the new-style commands:

¡ nas-port-type

¡ ip pool

¡ ipv6 pool

¡ ip pool-group

¡ ipv6 pool-group

You cannot disable BRAS device compatibility with old-style commands if any old-style command is effective. You cannot enable BRAS device compatibility with old-style commands if any new-style command is effective. An exception is that you can enable BRAS device compatibility with old-style commands regardless of whether you have executed the new-style nas-port-type command unless the command includes the cable keyword. After you enable this feature, you can still execute the nas-port-type command except for specifying the cable keyword.

If BRAS device compatibility with old-style commands has already been enabled and old-style commands have been executed, but the network management system requires support for new-style commands due to version upgrades, first remove all old-style command configurations and disable the old-style command compatibility feature. Then, execute new-style commands.

If you have executed new-style commands but the network management system does not support them after the device accesses the network management system and requires old-style commands, remove all configurations except the nas-port-type command. Also remove the nas-port-type cable command configuration, if any. Then, enable the compatibility with old-style commands on the device.

For more information about the dhcp pool-group, dhcp server ip-pool, ip pool, and ip pool-group commands, see BRAS Services Command Reference. For more information about the ip subscriber nas-port-type cable command, see BRAS Services Command Reference. For more information about the ipv6 dhcp pool, ipv6 dhcp pool-group, ipv6 pool, and ipv6 pool-group commands, see BRAS Services Command Reference.

Procedure

1. Enter system view.

system-view

2. Enable BRAS device compatibility with old-style commands.

bras compatible old-style-commands enable

By default, BRAS device compatibility with old-style commands is disabled.

Configuring the feature of retaining UNR host routes of users when an interface switches to backup

About this task

On a VSRP network, when the master interface switches to backup, the device automatically deletes the UNR host routes for all online users on that master interface by default. When the interface switches to the master interface, the device regenerates UNR host routes for all users that switch to the new master interface and come online.

With this feature enabled, when the master interface switches to backup, the device will retain the UNR host routes for all online users on that master interface. When the interface switches to master, the device directly uses the retained UNR host routes. This feature avoids regenerating UNR host routes for users that switch to the new master interface and improves switchover efficiency. This feature is applicable in the following scenario:

· When users do not need to access each other, you can enable this feature. This feature avoids the impact on switchover efficiency caused by generating UNR host routes for users that switch to the new master interface on the device.

· When users need to access each other, you must disable this feature to ensure mutual access.‌

Restrictions and guidelines

· This feature is only applicable to VSRP networks.‌

· When enabling this feature on a VSRP network, you must enable this feature on both the master and backup devices. If you do not do that, the feature might become unavailable.‌

Procedure

1. Enter system view.

system-view

2. Enable the feature of retaining UNR host routes of users when an interface switches to backup.

access-user interface-switchto-backup keep-host-routes

By default, the feature of retaining UNR host routes of users when an interface switches to backup is disabled.

Configuring the parameters for sending gratuitous ARP packets upon the master/backup UP switchover (on UPs)

About this task

In an UP backup network, if the master interface, master UP, or master network-side link fails, the CP will notify the backup UP interface to become the master. After the master/backup UP switchover, the new master interface will send gratuitous ARP packets. This allows connected devices to update their MAC address entries and switch service traffic to the new master interface.

To change the VLAN of the gratuitous ARP packets sent by the UP, execute the access-user interface send gratuitous-arp command:

· by-user-vlan: Specifies the new master interface and its subinterfaces to send gratuitous ARP packets as follows.

¡ The main interface directly sends gratuitous ARP packets without carrying a VLAN tag.

¡ Subinterface:

- In 1:1 hot standby mode:
If online users exist on a subinterface upon the master/backup UP switchover, the subinterface sends gratuitous ARP packets in the VLAN of a randomly selected user.
If no users are online on the subinterface upon the master/backup UP switchover, the subinterface does not send a gratuitous ARP packet.

- In other UP backup modes, a subinterface will send gratuitous ARP packets in the VLAN of a randomly selected user only when users come online on the subinterface.

· disable: Disables the UP from sending gratuitous ARP packets.

· on-all-vlans: Specifies the UP to send gratuitous ARP packets in all VLANs terminated on the new master interface.

When multiple interfaces on the UP need to send gratuitous ARP packets in multiple VLANs, a large number of packets will be sent each time. To avoid congestion caused by high sending rates and large quantities, perform the following tasks.

· Use the access-user send gratuitous-arp command to decrease the times for sending gratuitous ARP packets and increase the sending interval to avoid congestion caused by insufficient performance of the UP or its connected devices. The access-user send gratuitous-arp command specifies the times and intervals for sending gratuitous ARP packets in the same VLAN on an interface, rather than for the total packets sent by the interface.

· Use the access-user send gratuitous-arp rate-limit command to limit the maximum number of gratuitous ARP packets sent per second by the UP. The limit set by using the access-user send gratuitous-arp rate-limit command applies to each individual slot.

Restrictions and guidelines

The access-user interface send gratuitous-arp and access-user send gratuitous-arp commands only apply to the master/backup UP switchovers that have not occurred, and do not affect the ongoing switchover process.

Procedure

Table 1 ‍Enter system view.

system-view

2. On a UP backup network, configure how the UP sends gratuitous ARP packets upon the master/backup UP switchover.

access-user interface send gratuitous-arp { by-user-vlan | disable | on-all-vlans }

By default, the VLAN to which the gratuitous ARP packets sent by the UP belong depends on the VLAN termination method on the new master interface.

¡ Dot1q termination—For an interface configured with Dot1q termination, regardless of whether it is also configured with QinQ termination, the interface sends gratuitous ARP packets in the smallest VLAN specified in Dot1q termination.

¡ QinQ termination—For an interface configured with QinQ termination, the interface sends gratuitous ARP packets in the smallest outer VLAN specified in QinQ termination.

¡ Untagged/default termination—For an interface configured with untagged or default termination, the interface sends gratuitous ARP packets without any VLAN tags.

3. Configure the times and intervals for sending gratuitous ARP packets on the UP.

access-user send gratuitous-arp retry retries interval interval

By default, the times and intervals for sending gratuitous ARP packets on the UP vary by UP backup mode as follows:

¡ In 1:1 hot standby mode, the UP sends gratuitous ARP packets for three times at intervals of one second after the master/backup UP switchover.

¡ In both N:1 warm standby mode and 1:N warm load balancing mode, the UP send gratuitous ARP packets for 15 times after the master/backup UP switchover: sends the packets at intervals of one second for the first five times and at intervals of three seconds for the next 10 times.

4. Configure the maximum number of gratuitous ARP packets that the UP can send per second.

access-user send gratuitous-arp rate-limit rate

By default, the maximum number of gratuitous ARP packets that a UP can send per second is not limited.

Configuring CPU usage-based dynamic resource management

About this task

This feature allows the device to adjust user-related features based on CPU usage. It reduces device resource consumption and frees up CPU resources by limiting user access performance.

Enabling the CPU usage awareness feature on the device

About this task

Enable this feature to have the device adjust features based on CPU usage.

Procedure

1. Enter system view.

system-view

2. Enable the CPU usage awareness feature on the device.

access-user sense cpu-usage enable

By default, the CPU usage awareness feature is disabled on the device.

Enabling the device to adjust the user detection frequency based on CPU usage

About this task

When you enable the online user detection feature, the device sends a detection packet at each time interval by default. After you enable the device to adjust the user detection frequency based on CPU usage, the device sends a detection packet at double the time interval when the CPU usage reaches the minor level (level-1 alarm). The device sends a detection packet at triple the time interval when the CPU usage reaches the severe level (level-2 alarm).

Restrictions and guidelines

The ip subscriber adjustment user-detect cpu-usage and access-user adjustment user-detect enable commands are mutually exclusive. Do not execute both commands at the same time.

Procedure

1. Enter system view.

system-view

2. Enable the device to adjust the user detection frequency based on CPU usage.

access-user adjustment user-detect enable

By default, the device is not enabled to adjust the user detection frequency based on CPU usage.

Enabling the device to adjust the real-time accounting packet sending frequency based on CPU usage

About this task

By default, the device sends a real-time accounting update packet at each accounting interval. After you enable the device to adjust the real-time accounting packet sending frequency based on CPU usage, the device sends a real-time accounting update packet at double the time interval when the CPU usage reaches the minor level (level-1 alarm). The device sends a real-time accounting update packet at triple the time interval when the CPU usage reaches the severe level (level-2 alarm).

Procedure

1. Enter system view.

system-view

2. Enable the device to adjust the real-time accounting packet transmission frequency based on CPU usage.

access-user adjustment accounting-update enable

By default, the device is not enabled to adjust the real-time accounting packet sending frequency based on CPU usage.

Enabling the device to adjust the online user traffic statistics collection frequency based on CPU usage

About this task

After you enable the device to adjust the online user traffic statistics collection frequency based on CPU usage, the device collects online user traffic statistics at the slowest configurable frequency when the CPU usage reaches the minor level (level-1 alarm). The device collects online user traffic statistics at half the slowest configurable frequency when the CPU usage reaches the severe level (level-2 alarm).

Procedure

1. Enter system view.

system-view

2. Enable the device to adjust the online user traffic statistics collection frequency based on CPU usage.

access-user adjustment traffic enable

By default, the device is not enabled to adjust the online user traffic statistics collection frequency based on CPU usage.

Configuring the maximum number of concurrent online users allowed on the device and the threshold for recovering user access

About this task

In the current software version, you can control the maximum number of concurrent online users on the device in either of the following ways:

· Execute the access-user max-connections minor severe command: When the device's CPU usage reaches the minor or severe level, the device will reject new user connections after the specified maximum number of concurrent users is reached. This prevents excessive CPU resource consumption. When the number of online users on the device drops below the specified recovery threshold, the device can accept new users again to ensure normal operation.

· Execute the access-user max-connections command: The device will reject new user connections once the number of online users reaches the specified maximum number of concurrent users. This prevents excessive CPU resource usage. When the number of online users on the device drops below the specified recovery threshold, the device can accept new users again to ensure normal operation. This command sets a fixed effective value without considering CPU usage.

When you execute both the access-user max-connections and access-user max-connections minor severe commands, the following rules apply:

· If you specify the force keyword in the access-user max-connections command, the device uses the configured maximum number of concurrent users and recovery threshold for user access configured by using the access-user max-connections command.

· If you do not specify the force keyword in the access-user max-connections command, the device uses the configured maximum number of concurrent users and recovery threshold for user access configured by using the access-user max-connections command when the CPU usage is below the alarm threshold. If the device’s access authentication rate reaches the alarm threshold, the device uses the smaller configured value of the two commands.

Procedure

1. Enter system view.

system-view

2. Configure the maximum number of concurrent online users allowed on the device and the threshold for recovering user access. Choose at least one of the following options.

¡ Configure the maximum number of concurrent online users allowed on the device and the threshold for recovering user access at different CPU usages.

access-user max-connections minor max-number resume-number severe max-number resume-number

¡ Configure the maximum number of concurrent online users allowed on the device and the threshold for recovering user access.

access-user max-connections max-number resume-number [ force ]

By default, the device does not adjust the maximum number of concurrent online users allowed or the threshold for user access recovery based on CPU usage.

Configuring the access user authentication rate

About this task

In the current software version, you can control the access user authentication rate for the device in either of the following ways:

· Execute the access-user authen-rate minor severe command: When the device's CPU usage reaches the minor or severe level, the maximum number of authenticated access users allowed within the specified statistics collection interval is the specified value. The device will reject any users exceeding this upper limit to prevent excessive CPU resource consumption.

· Execute the access-user authen-rate command: The maximum number of authenticated access users allowed within the statistics collection interval specified by using this command is the specified value. The device will reject any users exceeding this upper limit to prevent excessive CPU resource consumption. This command sets a fixed authentication rate without considering CPU usage.

When you execute both the access-user authen-rate and access-user authen-rate minor severe commands, the following rules apply:

· If you specify the force keyword in the access-user authen-rate command, the device uses the authentication rate configured by using the access-user authen-rate command.

· If you do not specify the force keyword in the access-user authen-rate command, the device uses the authentication rate configured by using the access-user authen-rate command when the CPU usage is below the alarm threshold. If the CPU usage reaches the alarm threshold, the device uses the smaller authentication rate value configured by the two commands.

Procedure

1. Enter system view.

system-view

2. Configure the access user authentication rate. Choose at least one of the following options.

¡ Configure the access user authentication rate based on different CPU usage levels.

access-user authen-rate minor authen-number authen-period severe authen-number authen-period

¡ Configure the access user authentication rate for the device.

access-user authen-rate authen-number authen-period [ force ]

By default, the access user authentication rate is not configured.

Configure the user access rates at different CPU usage levels on the device

About this task

When the CPU usage of the device reaches the minor or severe level, the DHCPv4, DHCPv6, and PPPoE user access rate drops to the specified percentage of the maximum access rate. This prevents excessive CPU resource consumption.

Procedure

1. Enter system view.

system-view

2. Configure the user access rates at different CPU usage levels on the device.

access-user adjustment access-rate-limit minor access-rate severe access-rate

By default, the device is not enabled to adjust the access rate of online users based on CPU usage.

Enabling the CPU usage alarm logs on the device

About this task

Enable the CPU usage alarm logs to record when the CPU usage enters or exits the specified alarm threshold. The generated log messages by the device will be sent to the information center. The information center configuration specifies the log message sending rule and destination.

For more information about the information center, see information center configuration in Network Management and Monitoring Configuration Guide.

Procedure

1. Enter system view.

system-view

2. Enable the CPU usage alarm logs on the device.

access-user cpu-warning log enable

By default, the CPU usage alarm logs are disabled.

Configuring access user common management

Configuring service tracing objects

About this task

You can create service tracing objects to trace access user information, such as login and logout information. By specifying match parameters, you can trace the specific access users.

Restrictions and guidelines

This feature is resource intensive. As a best practice, configure this feature only when troubleshooting devices.

When the log server is specified as the output destination, make sure the device and the specified log server can reach each other and the log server configuration is correct.

(In standalone mode.) Active/standby MPU switchover causes the command to be ineffective.

(In IRF mode.) Active/standby global MPU switchover causes the command to be ineffective.

Procedure

1. Enter system view.

system-view

2. Configure a service tracing object.

trace access-user object object-id { access-mode { ipoe | lns | pppoe } | c-vlan vlan-id | interface interface-type interface-number | ip-address ip-address | mac-address mac-address | s-vlan vlan-id | tunnel-id tunnel-id | username user-name } * [ aging time | output { file file-name | syslog-server server-ip-address | vty } ] *

trace access-user object object-id [ access-mode { ipoe | lns | pppoe } | c-vlan vlan-id | interface interface-type interface-number | ip-address ip-address | mac-address mac-address | s-vlan vlan-id | tunnel-id tunnel-id | username user-name ] * calling-station-id calling-station-id

If you specify an interface, the service tracing object becomes ineffective when the slot or subslot that hosts the specified interface is rebooted.

Display and maintenance commands for UCM

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

Task	Command
Display access user information.	In standalone mode:‌ display access-user [ [ { { accounting-state { accounting \| idle \| leaving-flow-query \| ready \| wait-acct-start \| wait-acct-stop } \| [ all-vpn-instance \| public-instance \| vpn-instance vpn-instance-name ] \| auth-method { hwtacacs \| local \| none \| radius \| radius-proxy } \| auth-type { admin \| bind \| dot1x [ with-address \| without-address ] \| ppp \| pre-auth \| web-auth [ inherit-pppoe \| non-inherit-pppoe \| web-mac-auth \| web-mac-trigger \| web-normal ] } \| car cir cir-value [ pir pir-value ] [ inactive ] [ both \| inbound \| outbound ] \| domain domain-name [ authorization \| authentication ] \| flow-rate [ ip \| ipv6 ] { inbound { above rate-inbound-above-value \| below rate-inbound-below-value } * \| outbound { above rate-outbound-above-value \| below rate-outbound-below-value } * } * \| initiator-method { arp \| dhcpv4 \| dhcpv6 \| ndrs \| nsna \| unclassified-ip \| unclassified-ipv6 } \| interface interface-type interface-number [ all \| s-vlan svlan-id [ c-vlan cvlan-id ] ] \| ip-pool pool-name \| ip-pool-group ip-pool-groupname \| ip-type { dual-stack \| ipv4 \| ipv6 } \| { ipv4 multicast-user-profile profile-name \| ipv6 multicast-user-profile profile-name } * \| ipv6-address-protocol { dhcpv6 \| dhcpv6-pd \| nd } \| ipv6-cpe-mode { ipv6 \| ipv6-pd } \| ipv6-pool pool-name \| ipv6-pool-group ipv6-pool-groupname \| lac-ip lac-ip-address \| lns-ip lns-ip-address \| { { { local-access \| remote-access } \| { backup \| master } } * \| normal } \| mac-address mac-address \| nat-instance nat-instance-name \| pppoe-agency-state no-online \| quota-out-redirect \| radius-attribute-inexistence user-profile \| remote-name tunnel-name \| session-group-profile { session-group-profile-name \| [ session-group-profile-name ] inactive } \| start-time start-time start-date end-time end-time end-date \| user-address-type { ds-lite \| ipv6 \| nat64 \| private-ds \| private-ipv4 \| public-ds \| public-ipv4 } \| user-group { user-group-name \| [ user-group-name ] inactive } \| user-traffic [ ip \| ipv6 ] { inbound { above traffic-inbound-above-value { byte \| giga-byte \| kilo-byte \| mega-byte } \| below traffic-inbound-below-value { byte \| giga-byte \| kilo-byte \| mega-byte } } * \| outbound { above traffic-outbound-above-value { byte \| giga-byte \| kilo-byte \| mega-byte } \| below traffic-outbound-below-value { byte \| giga-byte \| kilo-byte \| mega-byte } } * } * \| user-priority { user-priority \| [ user-priority ] inactive } [ both \| inbound \| outbound ] \| user-profile { user-profile-name \| [ user-profile-name ] inactive } [ both \| inbound \| outbound ] \| user-type { l2vpn-leased \| lac \| layer2-dynamic \| layer2-family-leased \| layer2-interface-leased \| layer2-static \| layer2-subnet-leased \| layer3-dynamic \| layer3-interface-leased \| layer3-static \| layer3-subnet-leased \| leased \| leased-subuser \| lns \| pppoe \| pppoea } \| username user-name \| vxlan vxlan-id [ vxlan-id-max ] \| slot slot-number [ cpu cpu-number ] } * \| time time [ slot slot-number [ cpu cpu-number ] ] } [ count \| verbose ] \| { { ip-address ipv4-address \| ipv6-address ipv6-address \| ipv6-prefix ipv6-prefix/prefix-length \| public-ip-address public-ip-address } [ all-vpn-instance \| public-instance \| vpn-instance vpn-instance-name ] \| user-id user-id } [ slot slot-number [ cpu cpu-number ] ] [ verbose ] ] \| { count \| verbose } ] display access-user user-type pppoegw [ { username user-name \| ip-address ipv4-address \| vpn-instance vpn-instance-name \| s-vlan svlan-id [ c-vlan cvlan-id ] \| slot slot-number [ cpu cpu-number ] } * \| user-id user-id ] [ count \| verbose ] In IRF mode: display access-user [ [ { { accounting-state { accounting \| idle \| leaving-flow-query \| ready \| wait-acct-start \| wait-acct-stop } \| [ all-vpn-instance \| public-instance \| vpn-instance vpn-instance-name ] \| auth-method { hwtacacs \| local \| none \| radius \| radius-proxy } \| auth-type { admin \| bind \| dot1x [ with-address \| without-address ] \| ppp \| pre-auth \| web-auth [ inherit-pppoe \| non-inherit-pppoe \| web-mac-auth \| web-mac-trigger \| web-normal ] } \| car cir cir-value [ pir pir-value ] [ inactive ] [ both \| inbound \| outbound ] \| domain domain-name [ authorization \| authentication ] \| flow-rate [ ip \| ipv6 ] { inbound { above rate-inbound-above-value \| below rate-inbound-below-value } * \| outbound { above rate-outbound-above-value \| below rate-outbound-below-value } * } * \| initiator-method { arp \| dhcpv4 \| dhcpv6 \| ndrs \| nsna \| unclassified-ip \| unclassified-ipv6 } \| interface interface-type interface-number [ all \| s-vlan svlan-id [ c-vlan cvlan-id ] ] \| ip-pool pool-name \| ip-pool-group ip-pool-groupname \| ip-type { dual-stack \| ipv4 \| ipv6 } \| { ipv4 multicast-user-profile profile-name \| ipv6 multicast-user-profile profile-name } * \| ipv6-address-protocol { dhcpv6 \| dhcpv6-pd \| nd } \| ipv6-cpe-mode { ipv6 \| ipv6-pd } \| ipv6-pool pool-name \| ipv6-pool-group ipv6-pool-groupname \| lac-ip lac-ip-address \| lns-ip lns-ip-address \| { { { local-access \| remote-access } \| { backup \| master } } * \| normal } \| mac-address mac-address \| nat-instance nat-instance-name \| pppoe-agency-state no-online \| quota-out-redirect \| radius-attribute-inexistence user-profile \| remote-name tunnel-name \| session-group-profile { session-group-profile-name \| [ session-group-profile-name ] inactive } \| start-time start-time start-date end-time end-time end-date \| user-address-type { ds-lite \| ipv6 \| nat64 \| private-ds \| private-ipv4 \| public-ds \| public-ipv4 } \| user-group { user-group-name \| [ user-group-name ] inactive } \| user-traffic [ ip \| ipv6 ] { inbound { above traffic-inbound-above-value { byte \| giga-byte \| kilo-byte \| mega-byte } \| below traffic-inbound-below-value { byte \| giga-byte \| kilo-byte \| mega-byte } } * \| outbound { above traffic-outbound-above-value { byte \| giga-byte \| kilo-byte \| mega-byte } \| below traffic-outbound-below-value { byte \| giga-byte \| kilo-byte \| mega-byte } } * } * \| user-priority { user-priority \| [ user-priority ] inactive } [ both \| inbound \| outbound ] \| user-profile { user-profile-name \| [ user-profile-name ] inactive } [ both \| inbound \| outbound ] \| user-type { l2vpn-leased \| lac \| layer2-dynamic \| layer2-interface-leased \| layer2-static \| layer2-subnet-leased \| layer3-dynamic \| layer3-interface-leased \| layer3-static \| layer3-subnet-leased \| leased \| leased-subuser \| lns \| pppoe \| pppoea } \| username user-name \| vxlan vxlan-id [ vxlan-id-max ] \| chassis chassis-number slot slot-number [ cpu cpu-number ] } * \| time time [ chassis chassis-number slot slot-number [ cpu cpu-number ] ] } [ count \| verbose ] \| { { ip-address ipv4-address \| ipv6-address ipv6-address \| ipv6-prefix ipv6-prefix/prefix-length \| public-ip-address public-ip-address } [ all-vpn-instance \| public-instance \| vpn-instance vpn-instance-name ] \| user-id user-id } [ chassis chassis-number slot slot-number [ cpu cpu-number ] ] [ verbose ] ] \| { count \| verbose } ] display access-user user-type pppoegw [ { username user-name \| ip-address ipv4-address \| vpn-instance vpn-instance-name \| s-vlan svlan-id [ c-vlan cvlan-id ] \| chassis chassis-number slot slot-number [ cpu cpu-number ] } * \| user-id user-id ] [ count \| verbose ] In standalone mode:‌In IRF mode: display access-user all-slot [ { { accounting-state { accounting \| idle \| leaving-flow-query \| ready \| wait-acct-start \| wait-acct-stop } \| auth-method { hwtacacs \| local \| none \| radius \| radius-proxy } \| auth-type { admin \| bind \| dot1x [ with-address \| without-address ] \| ppp \| pre-auth \| web-auth [ web-mac-auth \| web-mac-trigger \| web-normal ] } \| car cir cir-value [ pir pir-value ] [ inactive ] [ both \| inbound \| outbound ] \| domain domain-name [ authorization \| authentication ] \| flow-rate [ ip \| ipv6 ] { inbound { above rate-inbound-above-value \| below rate-inbound-below-value } * \| outbound { above rate-outbound-above-value \| below rate-outbound-below-value } * } * \| initiator-method { arp \| dhcpv4 \| dhcpv6 \| ndrs \| nsna \| unclassified-ip \| unclassified-ipv6 } \| interface interface-type interface-number [ all \| s-vlan svlan-id [ c-vlan cvlan-id ] ] \| ip-pool pool-name \| ip-pool-group ip-pool-groupname \| ip-type { dual-stack \| ipv4 \| ipv6 } \| { ipv4 multicast-user-profile profile-name \| ipv6 multicast-user-profile profile-name } * \| ipv6-address-protocol { dhcpv6 \| nd } \| ipv6-cpe-mode { ipv6 \| ipv6-pd } \| ipv6-pool pool-name \| ipv6-pool-group ipv6-pool-groupname \| lac-ip lac-ip-address \| lns-ip lns-ip-address \| { { { local-access \| remote-access } \| { backup \| master } } * \| normal } \| mac-address mac-address \| nat-instance nat-instance-name \| pppoe-agency-state no-online \| quota-out-redirect \| radius-attribute-inexistence user-profile \| remote-name tunnel-name \| session-group-profile { session-group-profile-name \| [ session-group-profile-name ] inactive } \| start-time start-time start-date end-time end-time end-date \| user-address-type { ds-lite \| ipv6 \| nat64 \| private-ds \| private-ipv4 \| public-ds \| public-ipv4 } \| user-group { user-group-name \| [ user-group-name ] inactive } \| user-traffic [ ip \| ipv6 ] { inbound { above traffic-inbound-above-value { byte \| giga-byte \| kilo-byte \| mega-byte } \| below traffic-inbound-below-value { byte \| giga-byte \| kilo-byte \| mega-byte } } * \| outbound { above traffic-outbound-above-value { byte \| giga-byte \| kilo-byte \| mega-byte } \| below traffic-outbound-below-value { byte \| giga-byte \| kilo-byte \| mega-byte } } * } * \| user-priority { user-priority \| [ user-priority ] inactive } [ both \| inbound \| outbound ] \| user-profile { user-profile-name \| [ user-profile-name ] inactive } [ both \| inbound \| outbound ] \| user-type { l2vpn-leased \| lac \| layer2-dynamic \| layer2-interface-leased \| layer2-static \| layer2-subnet-leased \| layer3-dynamic \| layer3-interface-leased \| layer3-static \| layer3-subnet-leased \| leased \| leased-subuser \| lns \| pppoe } \| username user-name \| vpn-instance vpn-instance-name \| vxlan vxlan-id [ vxlan-id-max ] } * \| time time } ] count
Display accounting state statistics of access users.	display access-user { accounting-state \| backup-role \| session-state } statistics [ [ all-vpn-instance \| public-instance \| vpn-instance vpn-instance-name ] \| domain domain-name [ authorization \| authentication ] \| interface interface-type interface-number [ all \| s-vlan svlan-id [ c-vlan cvlan-id ] ] \| ip-pool pool-name \| ip-pool-group ip-pool-groupname \| ip-type { dual-stack \| ipv4 \| ipv6 } \| ipv6-address-protocol { dhcpv6 \| dhcpv6-pd \| nd } \| ipv6-pool pool-name \| ipv6-pool-group ipv6-pool-groupname \| lac-ip lac-ip-address \| lns-ip lns-ip-address \| nat-instance nat-instance-name \| remote-name tunnel-name \| user-group { user-group-name \| [ user-group-name ] inactive } \| user-type { l2vpn-leased \| lac \| layer2-dynamic \| layer2-family-leased \| layer2-interface-leased \| layer2-static \| layer2-subnet-leased \| layer3-dynamic \| layer3-interface-leased \| layer3-static \| layer3-subnet-leased \| leased \| leased-subuser \| lns \| pppoe \| pppoea } ] *
Display the access user backup state on each slot.	display access-user backup-state
Display offline reason and online reason statistics of access users.	display access-user offline-reason statistics [ verbose ]
Display access user information on an UP.	Syntax I: display access-user user-plane [ [ all-vpn-instance \| public-instance \| vpn-instance vpn-instance-name ] \| auth-type { bind \| ppp \| pre-auth \| web-auth } \| interface interface-type interface-number [ s-vlan svlan-id [ c-vlan cvlan-id ] ] \| { ip-address ipv4-address \| ipv6-address ipv6-address } \| ip-type { dual-stack \| ipv4 \| ipv6 } \| lac-ip lac-ip-address \| lns-ip lns-ip-address \| nat-instance nat-instance-name \| mac-address mac-address \| slot slot-number [ cpu cpu-number ] \| user-type { l2vpn-leased \| lac \| layer2-dynamic \| layer2-interface-leased \| layer2-static \| layer2-subnet-leased \| layer3-dynamic \| layer3-interface-leased \| layer3-static \| layer3-subnet-leased \| leased \| leased-subuser \| lns \| pppoe } \| user-id user-id \| up-escape \| up-not-escape ] * [ count \| verbose ] Syntax II: display access-user user-plane all-slot [ auth-type { bind \| mac-auth \| ppp \| pre-auth \| web-auth } \| interface interface-type interface-number [ s-vlan svlan-id [ c-vlan cvlan-id ] ] \| { ip-address ipv4-address \| ipv6-address ipv6-address } [ vpn-instance vpn-instance-name ] \| ip-type { dual-stack \| ipv4 \| ipv6 } \| lac-ip lac-ip-address \| lns-ip lns-ip-address \| nat-instance nat-instance-name \| mac-address mac-address \| user-type { l2vpn-leased \| lac \| layer2-dynamic \| layer2-interface-leased \| layer2-static \| layer2-subnet-leased \| layer3-dynamic \| layer3-interface-leased \| layer3-static \| layer3-subnet-leased \| leased \| leased-subuser \| lns \| pppoe } \| user-id user-id \| vpn-instance vpn-instance-name \| up-escape \| up-not-escape ] * count ‌
Display the packet loss ratio statistics for access user detection packets.‌	In standalone mode:‌ display access-user user-detect packet-loss-ratio [ interface interface-type interface-number [ s-vlan svlan-id ] ] [ slot slot-number [ cpu cpu-number ] ] In IRF mode: display access-user user-detect packet-loss-ratio [ interface interface-type interface-number [ s-vlan svlan-id ] ] [ chassis chassis-number slot slot-number [ cpu cpu-number ] ]
Display the BRAS configuration and the number of users on an interface.	display bras-interface [ interface-type interface-number ] access-user-count
Display the BRAS configuration and running information on an interface.	In standalone mode:‌ display bras-interface [ interface-type interface-number ] configuration [ slot slot-number [ cpu cpu-number ] ] In IRF mode: display bras-interface [ interface-type interface-number ] configuration [ chassis chassis-number slot slot-number [ cpu cpu-number ] ]
Display the number of BRAS users by VLAN on an interface.	display bras-interface interface-type interface-number users-by-vlan [ s-vlan s-vlan-id [ c-vlan c-vlan-id ] ]
Display history information about the peak user counts.	In standalone mode:‌ display max-user history [ slot slot-number [ cpu cpu-number ] ] In IRF mode: display max-user history [ chassis chassis-number slot slot-number [ cpu cpu-number ] ]
Display service tracing object configuration information.	display trace access-user [ object object-id ]
Display the configuration and status information related to the maximum number of concurrent online users.	display access-user max-connections status [ history ]
Display the configuration and status of the access user authentication rate on the device.	display access-user authen-rate status [ history ]
Forcibly log out users.	In standalone mode:‌ cut access-user [ { auth-type { admin \| bind \| dot1x [ with-address \| without-address ] \| ppp \| pre-auth \| web-auth [ inherit-pppoe \| non-inherit-pppoe ] } \| domain domain-name [ authentication \| authorization ] \| interface interface-type interface-number [ s-vlan svlan-id [ c-vlan cvlan-id ] ] \| ip-pool pool-name \| ip-type { dual-stack \| ipv4 \| ipv6 } \| ipv6-pool pool-name \| mac-address mac-address \| nat-instance nat-instance-name \| user-address-type { ds-lite \| ipv6 \| nat64 \| private-ds \| private-ipv4 \| public-ds \| public-ipv4 } \| user-profile profile-name [ both \| inbound \| outbound ] \| user-type { l2vpn-leased \| lac \| layer2-dynamic \| layer2-family-leased \| layer2-interface-leased \| layer2-static \| layer2-subnet-leased \| layer3-dynamic \| layer3-interface-leased \| layer3-static \| layer3-subnet-leased \| leased \| leased-subuser \| lns \| pppoe \| pppoea } \| username user-name \| vpn-instance vpn-instance-name \| vxlan vxlan-id [ vxlan-id-max ] \| slot slot-number [ cpu cpu-number ] } * \| { { ip-address ipv4-address \| ipv6-address ipv6-address \| ipv6-prefix prefix-address/prefix-length } [ vpn-instance vpn-instance-name ] \| user-id user-id } ] cut access-user user-type pppoegw [ { username user-name \| ip-address ipv4-address \| vpn-instance vpn-instance-name \| s-vlan svlan-id [ c-vlan cvlan-id ] \| slot slot-number [ cpu cpu-number ] } * \| user-id user-id ] In IRF mode: cut access-user [ { auth-type { admin \| bind \| dot1x [ with-address \| without-address ] \| ppp \| pre-auth \| web-auth [ inherit-pppoe \| non-inherit-pppoe ] } \| domain domain-name [ authentication \| authorization ] \| interface interface-type interface-number [ s-vlan svlan-id [ c-vlan cvlan-id ] ] \| ip-pool pool-name \| ip-type { dual-stack \| ipv4 \| ipv6 } \| ipv6-pool pool-name \| mac-address mac-address \| nat-instance nat-instance-name \| user-address-type { ds-lite \| ipv6 \| nat64 \| private-ds \| private-ipv4 \| public-ds \| public-ipv4 } \| user-profile profile-name [ both \| inbound \| outbound ] \| user-type { l2vpn-leased \| lac \| layer2-dynamic \| layer2-family-leased \| layer2-interface-leased \| layer2-static \| layer2-subnet-leased \| layer3-dynamic \| layer3-interface-leased \| layer3-static \| layer3-subnet-leased \| leased \| leased-subuser \| lns \| pppoe \| pppoea } \| username user-name \| vpn-instance vpn-instance-name \| vxlan vxlan-id [ vxlan-id-max ] \| chassis chassis-number slot slot-number [ cpu cpu-number ] } * \| { { ip-address ipv4-address \| ipv6-address ipv6-address \| ipv6-prefix prefix-address/prefix-length } [ vpn-instance vpn-instance-name ] \| user-id user-id } ] cut access-user user-type pppoegw [ { username user-name \| ip-address ipv4-address \| vpn-instance vpn-instance-name \| s-vlan svlan-id [ c-vlan cvlan-id ] \| chassis chassis-number slot slot-number [ cpu cpu-number ] } * \| user-id user-id ]
Clear offline reason statistics of access users.	reset access-user offline-reason statistics
Clear the packet loss ratio statistics for the access user detection packets on the device. ‌	In standalone mode:‌ reset access-user user-detect packet-loss-ratio [ interface interface-type interface-number ] [ slot slot-number [ cpu cpu-number ] ] In IRF mode: reset access-user user-detect packet-loss-ratio [ interface interface-type interface-number ] [ chassis chassis-number slot slot-number [ cpu cpu-number ] ]
Clear history information about the peak user counts.	In standalone mode:‌ reset max-user history [ slot slot-number [ cpu cpu-number ] ] In IRF mode: reset max-user history [ chassis chassis-number slot slot-number [ cpu cpu-number ] ]

17-BRAS Services Configuration Guide

Configuring UCM

About UCM

CUPS in UCM

UCM tasks at a glance

Configuring the CUPS mode

About this task

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure

About this task

Setting the per-slot user count alarm threshold

About this task

Procedure

Configuring the packet loss ratio alarm for access user detection packets‌

About this task

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure

Configuring the NAS-Port-Type attribute for an interface

About this task

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure

Configure the escape rules for parameters in the web server URL redirected by the device to users‌

About this task

Application scenarios

Operating mechanism

Restrictions and guidelines

Procedure

About this task

Application scenarios

Operating mechanism

Restrictions and guidelines

Procedure

About this task

Application scenarios

Operating mechanism

Restrictions and guidelines

Procedure

About this task

Application scenarios

Operating mechanism

Restrictions and guidelines

Procedure

Configuring BRAS device compatibility with old-style commands‌

About this task

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure

About this task

Procedure