This document provides generic BRAS services troubleshooting procedures for H3C BRAS devices. Some of the information might not apply to your device depending on its software and hardware version.

The interface numbers in this documentation are for illustration only. They might differ from the interface numbers available on your device.

For more information on debugging commands mentioned in this document, see the debugging command references for the products.

The following information is provided based on the assumption that you have basic knowledge of BRAS services and are familiar with H3C BRAS devices.

General troubleshooting flow and diagnostic information collection for BRAS services

General troubleshooting flow

The following information provides a general high-level troubleshooting procedure for quick isolation of the problematic module and failure cause. You can modify this procedure based on your expertise and experience for effective troubleshooting of issues that differ in severity and complexity.

1. Identify the service impact scope of the failure.

Identify the following items:

¡ Affected subscriber services (for example, broadband and IPTV).

¡ The access services (for example, PPPoE and IPoE) used on the BRAS device to deliver the subscriber services.

¡ The number of affected users.

2. Identify the network topology.

This step is essential to troubleshooting BRAS issues, which are typically pertinent to the network.

3. Identify manual operations done on the network before and after the issue occurs.

Manual operations include configuration change and business cutover. This step helps narrow down the triggers of the issue quickly.

4. Analyze the characteristics of the affected users to find out if they have anything in common.

Examples of commonalities include the same access mode and the same Layer 2 switch.

5. Identify the point of failure.

Many times, network issues are caused by non-BRAS devices on the network. After you rule out the BRAS device, assist the customer in identifying the point of failure by using tools such as QoS flow statistics and port mirroring.

6. Identify the severity of the issue impact.

This step determines the action to take.

¡ If the impact is severe, quickly gather user information and take prompt action to restore services.

¡ If the impact is trivial, preferentially identify the cause of the issue and then remove the issue.

General BRAS troubleshooting procedures by plane

BRAS troubleshooting is divided into control plane troubleshooting and data plane troubleshooting.

· Control plane—Establishes, controls, and maintains network connectivity. It contains routing, signaling, and control protocols for routing, MPLS, and link layer connectivity. The protocols in the control plane generate and issue forwarding entries to the data plane to control its forwarding behaviors.

· Data plane—Also called the forwarding plane. It contains functionalities for receiving packets (including packets destined for the local node), forwarding data packets destined for remote nodes, and sending locally generated packets. Examples of data plane functionalities include the IPv4 and IPv6 protocol stacks, sockets, and functionalities that forward packets based on the forwarding tables at different layers.

General troubleshooting procedure for the control plane

Figure 1 shows the components used for BRAS user authentication and access. The User Connection Management (UCM) component is the bridge between the other components. It facilitates interaction between the components and assists in the establishment, maintenance, and termination of user connections.

Figure 1 Basic components used for BRAS user authentication and access

The following information describes the basic functionality of each component:

· User access identification component—Identifies and processes various user access protocol packets and obtains important user information such usernames, passwords, and physical locations during authentication. This information helps ensure secure and legitimate user access.

· UCM—Connects the other components to facilitate interaction between them and assists in the establishment, maintenance, and termination of user connections.

· AAA—Works with the AAA server to provide 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 privileges, bandwidth, and QoS policies for the users to access basic services and value-added services.

The following information provides the general procedure to troubleshoot the control plane:

1. Collect information about the affected users, including their usernames, MAC addresses, and VLANs.

Execute the trace access-user command to trace the network access flow for an affected user, from login and authentication to address allocation. You can use the debugging output from this command to identify the phase in which the failure occurred.

[bras] trace access-user object 1 ?

access-mode Specify users by access mode

c-vlan Specify users by Customer-VLAN

calling-station-id Specify users by calling station ID

interface Specify users by interface

ip-address Specify a user by IP address

mac-address Specify users by MAC address

s-vlan Specify users by Service-VLAN

tunnel-id Specify users by tunnel ID

username Specify a user by username

2. Examine the configuration for the identified erroneous point and correct the misconfiguration, if any.

3. If the configuration is correct, examine the related modules such as the access, AAA (or RADIUS), address allocation, portal, and L2TP modules for errors. For more information on debugging commands, see the debugging command references for the products.

NOTE:

After you enable service tracing by using the trace access-user command, you can use the display trace access-user command to view the configuration for the traced object. This command also displays the remaining amount of time for the trace session. When the remaining amount of time becomes 0, the trace session expires. To trace the same object, you must re-enable service tracing.

General troubleshooting procedure for the data plane

H3C BRAS devices provide hardware-based forwarding. The data plane is not error prone. If you receive reports on data traffic issues such as inaccurate rate limiting, packet loss, or loss of connectivity, take the following actions:

1. Verify that the user is online.

2. Verify that the rate limit and other authorization attributes assigned by the server to the user are correct.

3. Verify that data traffic from the user can arrive at the BRAS device.

4. If the issue persists, collect fault information and contact technical support for help.

Collecting user information

Service restoration is the top priority in dealing with a service outage while troubleshooting typically takes time. It is not always possible to promptly identify the cause of service outage solely based on debugging information. To assist in later troubleshooting, you must collect user information while restoring services.

The following are the best practices for user information collection:

· If only one user is affected, collect data that each module has for the affected user and some of the unaffected users to do a comparative analysis.

· If multiple users are affected, collect information about all affected users as soon as possible and contact technical support.

User information collection is to collect information about online users and users that were logged off abnormally. H3C BRAS devices offer a broad set of commands for you to collect user information. The following information describes only those used most commonly.

Support for the parameters in the commands described in this document differs depending on the hardware platform and software version.

Collecting information about online users

This task collects information about normal online users and temporary users, as well residual user information that should have been deleted.

Before you use the commands in this document to collect user information for troubleshooting purposes, read the command reference for the device to identify what information each parameter can produce. This will help you collect useful information efficiently.

For example, to collect complete information about a single user, execute the commands with the verbose keyword.

Collecting information for troubleshooting the PPPoE module

1. Execute the following command to collect information about PPP users that use the PPPoE access service. This command is the primary command you use to collect information about PPP users.

<Sysname> display access-user user-type pppoe ?

> Redirect it to a file

>> Redirect it to a file in append mode

accounting-state Specify users by accounting state

all-vpn-instance All VPN instances

auth-method Specify users by authentication method

auth-type Specify a user by authentication type

backup Display backup user

car Specify a CAR for users

count Display the total number of users

domain Specify users by ISP domain

flow-rate User flow rate

initiator-method Specify users by initiator method

interface Specify users by interface

ip-pool Specify users by an IP pool

ip-pool-group Specify users by an IP pool group

ip-type Specify users by IP type

ipv4 IPv4

ipv6 IPv6

ipv6-address-protocol Specify users by IPv6 address protocol

ipv6-cpe-mode IPv6 CPE mode

ipv6-pool Specify users by an IPv6 pool

ipv6-pool-group Specify users by an IPv6 pool group

lac-ip Specify users by the IP address of an LAC

lns-ip Specify users by the IP address of an LNS

local-access Display local-access user

mac-address Specify a user by MAC address

master Display master user

nat-instance Specify users by NAT instance

normal Display non-CP disaster-recovery or non-VSRP

user

pppoe-agency-state Specify users by PPPoE agency state

public-instance Public instance

quota-out-redirect Specify users in redirect state after quota is

used out

radius-attribute-inexistence No RADIUS attribute assigned

remote-access Display remote-access user

remote-name Specify users by the tunnel name

session-group-profile Specify a session group profile

slot Specify the slot number

start-time Specify users by the start time of coming online

user-address-type Specify users by address type

user-group Specify users by a user group

user-priority Specify a user priority

user-profile Specify a user profile

user-traffic User traffic

username Specify a user by username

verbose Display detailed information about users

vpn-instance Specify a VPN instance

vxlan Specify users by a range of VXLANs

| Matching output

<cr>

2. Execute the following command to collect statistics and information on the PPPoE server for online users.

<Sysname> display pppoe-server ?

chasten PPPoE connection blocking

packet Packet statistics

session PPPoE session information

throttled-mac Throttled MAC information

Collecting information for troubleshooting the IPoE module

1. Execute the following command to collect information about IPoE users, including IPoE Web users.

<Sysname> display access-user auth-type ?

admin Admin authentication

bind Bind authentication

dot1x 802.1X authentication

ike IKE authentication

mac-auth Mac authentication

portal Portal authentication

ppp PPP authentication

pre-auth Pre web authentication

web-auth Web authentication

2. Execute the following command to collect information about IPoE bind authentication users.

<Sysname> display access-user auth-type bind ?

> Redirect it to a file

>> Redirect it to a file in append mode

accounting-state Specify users by accounting state

all-vpn-instance All VPN instances

auth-method Specify users by authentication method

backup Display backup user

car Specify a CAR for users

count Display the total number of users

domain Specify users by ISP domain

flow-rate User flow rate

initiator-method Specify users by initiator method

interface Specify users by interface

ip-pool Specify users by an IP pool

ip-pool-group Specify users by an IP pool group

ip-type Specify users by IP type

ipv4 IPv4

ipv6 IPv6

ipv6-address-protocol Specify users by IPv6 address protocol

ipv6-cpe-mode IPv6 CPE mode

ipv6-pool Specify users by an IPv6 pool

ipv6-pool-group Specify users by an IPv6 pool group

lac-ip Specify users by the IP address of an LAC

lns-ip Specify users by the IP address of an LNS

local-access Display local-access user

mac-address Specify a user by MAC address

master Display master user

nat-instance Specify users by NAT instance

normal Display non-CP disaster-recovery or non-VSRP

user

pppoe-agency-state Specify users by PPPoE agency state

public-instance Public instance

quota-out-redirect Specify users in redirect state after quota is

used out

radius-attribute-inexistence No RADIUS attribute assigned

remote-access Display remote-access user

remote-name Specify users by the tunnel name

session-group-profile Specify a session group profile

slot Specify the slot number

start-time Specify users by the start time of coming online

user-address-type Specify users by address type

user-group Specify users by a user group

user-priority Specify a user priority

user-profile Specify a user profile

user-traffic User traffic

user-type Specify users by type

username Specify a user by username

verbose Display detailed information about users

vpn-instance Specify a VPN instance

vxlan Specify users by a range of VXLANs

| Matching output

<cr>

Collecting information for troubleshooting the L2TP module

1. Execute the following command to collect information about L2TP sessions.

<Sysname> display l2tp session ?

> Redirect it to a file

>> Redirect it to a file in append mode

lac Display L2TP session information of LAC

lns Display L2TP session information of LNS

local-address Specify sessions by the local IP address

remote-address Specify sessions by the remote IP address

statistics Statistics information

temporary L2TP temporary session information

tunnel-id Specify sessions by the specified local tunnel ID

username Specify sessions by the username

verbose Display detailed L2TP session information

| Matching output

<cr>

2. Execute the following command to collect information about temporary L2TP sessions.

<Sysname> display l2tp session temporary ?

> Redirect it to a file

>> Redirect it to a file in append mode

| Matching output

<cr>

3. Execute the following command to collect information about L2TP tunnels.

<Sysname> display l2tp tunnel ?

> Redirect it to a file

>> Redirect it to a file in append mode

group-name Specify tunnels by the group name

group-number Specify tunnels by the group number

lac Display L2TP tunnel information of LAC

lns Display L2TP tunnel information of LNS

local-address Specify tunnels by the local IP address

remote-address Specify tunnels by the remote IP address

statistics Statistics information

tunnel-id Specify tunnels by the local L2TP tunnel ID

tunnel-name Specify tunnels by the remote tunnel name

verbose Display detailed L2TP tunnel information

vsrp L2TP VSRP tunnel information

| Matching output

<cr>

4. Execute the following command on the LAC to collect information about PPP users that access the network through L2TP.

<Sysname> display access-user user-type lac ?

> Redirect it to a file

>> Redirect it to a file in append mode

accounting-state Specify users by accounting state

all-vpn-instance All VPN instances

auth-method Specify users by authentication method

auth-type Specify a user by authentication type

backup Display backup user

car Specify a CAR for users

count Display the total number of users

domain Specify users by ISP domain

flow-rate User flow rate

initiator-method Specify users by initiator method

interface Specify users by interface

ip-pool Specify users by an IP pool

ip-pool-group Specify users by an IP pool group

ip-type Specify users by IP type

ipv4 IPv4

ipv6 IPv6

ipv6-address-protocol Specify users by IPv6 address protocol

ipv6-cpe-mode IPv6 CPE mode

ipv6-pool Specify users by an IPv6 pool

ipv6-pool-group Specify users by an IPv6 pool group

lac-ip Specify users by the IP address of an LAC

lns-ip Specify users by the IP address of an LNS

local-access Display local-access user

mac-address Specify a user by MAC address

master Display master user

nat-instance Specify users by NAT instance

normal Display non-CP disaster-recovery or non-VSRP

user

pppoe-agency-state Specify users by PPPoE agency state

public-instance Public instance

quota-out-redirect Specify users in redirect state after quota is

used out

radius-attribute-inexistence No RADIUS attribute assigned

remote-access Display remote-access user

remote-name Specify users by the tunnel name

session-group-profile Specify a session group profile

slot Specify the slot number

start-time Specify users by the start time of coming online

user-address-type Specify users by address type

user-group Specify users by a user group

user-priority Specify a user priority

user-profile Specify a user profile

user-traffic User traffic

username Specify a user by username

verbose Display detailed information about users

vpn-instance Specify a VPN instance

vxlan Specify users by a range of VXLANs

| Matching output

<cr>

5. Execute the following command on the LNS to collect information about PPP users that access the network through L2TP.

<Sysname> display access-user user-type lns ?

> Redirect it to a file

>> Redirect it to a file in append mode

accounting-state Specify users by accounting state

all-vpn-instance All VPN instances

auth-method Specify users by authentication method

auth-type Specify a user by authentication type

backup Display backup user

car Specify a CAR for users

count Display the total number of users

domain Specify users by ISP domain

flow-rate User flow rate

initiator-method Specify users by initiator method

interface Specify users by interface

ip-pool Specify users by an IP pool

ip-pool-group Specify users by an IP pool group

ip-type Specify users by IP type

ipv4 IPv4

ipv6 IPv6

ipv6-address-protocol Specify users by IPv6 address protocol

ipv6-cpe-mode IPv6 CPE mode

ipv6-pool Specify users by an IPv6 pool

ipv6-pool-group Specify users by an IPv6 pool group

lac-ip Specify users by the IP address of an LAC

lns-ip Specify users by the IP address of an LNS

local-access Display local-access user

mac-address Specify a user by MAC address

master Display master user

nat-instance Specify users by NAT instance

normal Display non-CP disaster-recovery or non-VSRP

user

pppoe-agency-state Specify users by PPPoE agency state

public-instance Public instance

quota-out-redirect Specify users in redirect state after quota is

used out

radius-attribute-inexistence No RADIUS attribute assigned

remote-access Display remote-access user

remote-name Specify users by the tunnel name

session-group-profile Specify a session group profile

slot Specify the slot number

start-time Specify users by the start time of coming online

user-address-type Specify users by address type

user-group Specify users by a user group

user-priority Specify a user priority

user-profile Specify a user profile

user-traffic User traffic

username Specify a user by username

verbose Display detailed information about users

vpn-instance Specify a VPN instance

vxlan Specify users by a range of VXLANs

| Matching output

<cr>

Collecting information for troubleshooting the DHCP module

1. Collect information about the idle IP addresses available for allocation on the DHCP server.

<Sysname> display dhcp server free-ip ?

> Redirect it to a file

>> Redirect it to a file in append mode

pool Specify a DHCP pool

vpn-instance Specify a VPN instance

| Matching output

<cr>

2. Collect information about the allocated IP addresses that are in use on the DHCP server.

<Sysname> display dhcp server ip-in-use ?

> Redirect it to a file

>> Redirect it to a file in append mode

interface Specify the interface

ip Specify an IP address

pool Specify a DHCP pool

pool-group Specify a DHCP pool-group

subnet Specify subnet

vpn-instance Specify a VPN instance

vxlan Specify a VXLAN

| Matching output

<cr>

3. Collect information about IP and MAC bindings in expired leases on the DHCP server.

<Sysname> display dhcp server expired ?

> Redirect it to a file

>> Redirect it to a file in append mode

interface Specify the interface

ip Specify an IP address

mac Specify a MAC address

pool Specify a DHCP pool

verbose Detailed information

vpn-instance Specify a VPN instance

vxlan Specify a VXLAN

| Matching output

<cr>

4. Collect information about IP and MAC bindings recorded for IP address conflict on the DHCP server.

<Sysname> display dhcp server conflict ?

> Redirect it to a file

>> Redirect it to a file in append mode

interface Specify the interface

ip Specify an IP address

vpn-instance Specify a VPN instance

vxlan Specify a VXLAN

| Matching output

<cr>

5. Collect information about client address entries recorded on the DHCP relay agent.

<Sysname> display dhcp relay client-information ?

> Redirect it to a file

>> Redirect it to a file in append mode

interface Specify the interface

ip Specify an IP address

| Matching output

<cr>

Collecting information for troubleshooting the AAA module

No commands are available for the AAA module to record user information. To obtain information about AAA users, use the information recorded by the access modules.

Collecting information about abnormally logged-off users

You collect information about abnormally logged-off users for analysis of the recorded logoff reasons and message exchanges between modules to identify the root cause of the abnormal logoffs.

Collecting information for troubleshooting the PPPoE module

1. Collect PPPoE server negotiation packet statistics.

<Sysname> display pppoe-server packet statistics ?

> Redirect it to a file

>> Redirect it to a file in append mode

slot Specify the slot number

| Matching output

<cr>

2. Collect PPP negotiation packet statistics.

<Sysname> display ppp packet statistics ?

> Redirect it to a file

>> Redirect it to a file in append mode

slot Specify the slot number

| Matching output

<cr>

3. Collect the offline records for login users.

<Sysname> display aaa offline-record access-type ppp ?

> Redirect it to a file

>> Redirect it to a file in append mode

brief Display brief information

count Specify the number of records to be displayed

domain Specify an ISP domain

interface Specify an interface

ip Specify an IPv4 address

ipv6 Specify an IPv6 address

mac-address Specify a MAC address

reason-code Specify a reason code

s-vlan Specify a service provider network VLAN

slot Specify the slot number

time Specify a time range

username Specify a username

| Matching output

<cr>

Collecting information for troubleshooting the IPoE module

1. Collect information about abnormally logged-off DHCP clients.

<Sysname> display ip subscriber abnormal-logout ?

> Redirect it to a file

>> Redirect it to a file in append mode

access-type Specify users by access type

ip Specify the IP address

ip-type Specify users by IP type

ipv6 Specify the IPv6 address

ipv6-prefix Specify an IPv6 prefix

mac Specify a MAC address

slot Specify the slot number

verbose Detailed information

vsrp-instance Specify VSRP instance name

| Matching output

<cr>

2. Collect the offline records for IPoE users.

<Sysname> display aaa offline-record access-type ipoe ?

> Redirect it to a file

>> Redirect it to a file in append mode

brief Display brief information

count Specify the number of records to be displayed

domain Specify an ISP domain

interface Specify an interface

ip Specify an IPv4 address

ipv6 Specify an IPv6 address

mac-address Specify a MAC address

reason-code Specify a reason code

s-vlan Specify a service provider network VLAN

slot Specify the slot number

time Specify a time range

username Specify a username

| Matching output

<cr>

3. Collect statistics for IPoE users.

<Sysname> display access-user count ?

> Redirect it to a file

>> Redirect it to a file in append mode

| Matching output

<cr>

Collecting information for troubleshooting the L2TP module

1. Collect L2TP protocol packet statistics.

<Sysname> display l2tp control-packet statistics ?

> Redirect it to a file

>> Redirect it to a file in append mode

summary Summary L2TP control packet statistics

tunnel L2TP control packet statistics of each tunnel

| Matching output

<cr>

2. Collect L2TP statistics.

<Sysname> display l2tp statistics ?

all All L2TP statistics

failure-reason Failure reason statistics

vsrp VSRP statistics

Collecting information for troubleshooting the DHCP module

1. Collect DHCP server statistics.

<Sysname> display dhcp server statistics ?

> Redirect it to a file

>> Redirect it to a file in append mode

domain Specify an ISP Domain

pool Specify a DHCP pool

pool-group Specify a DHCP pool group

vpn-instance Specify a VPN instance

| Matching output

<cr>

2. Collect DHCP relay statistics.

<Sysname> display dhcp relay packet statistics ?

> Redirect it to a file

>> Redirect it to a file in append mode

interface Specify the interface

| Matching output

<cr>

Collecting information for troubleshooting the AAA module

1. Collect the abnormal offline records maintained by the AAA module.

<Sysname> display aaa abnormal-offline-record ?

> Redirect it to a file

>> Redirect it to a file in append mode

access-type Specify an access type

domain Specify an ISP domain

interface Specify an interface

ip Specify an IPv4 address

ipv6 Specify an IPv6 address

mac-address Specify a MAC address

offline-reason Specify a user offline reason

reason-code Specify a reason code

s-vlan Specify a service provider network VLAN

slot Specify the slot number

time Specify a time range

username Specify a username

| Matching output

<cr>

2. Collect the normal offline records maintained by the AAA module.

<Sysname> display aaa normal-offline-record ?

> Redirect it to a file

>> Redirect it to a file in append mode

access-type Specify an access type

domain Specify an ISP domain

interface Specify an interface

ip Specify an IPv4 address

ipv6 Specify an IPv6 address

mac-address Specify a MAC address

reason-code Specify a reason code

s-vlan Specify a service provider network VLAN

slot Specify the slot number

time Specify a time range

username Specify a username

| Matching output

<cr>

3. Collect the offline records maintained by the AAA module.

<Sysname> display aaa offline-record ?

> Redirect it to a file

>> Redirect it to a file in append mode

access-type Specify an access type

domain Specify an ISP domain

interface Specify an interface

ip Specify an IPv4 address

ipv6 Specify an IPv6 address

mac-address Specify a MAC address

reason-code Specify a reason code

s-vlan Specify a service provider network VLAN

slot Specify the slot number

time Specify a time range

username Specify a username

| Matching output

<cr>

4. Collect the user online failure records maintained by the AAA module.

<Sysname> display aaa online-fail-record ?

> Redirect it to a file

>> Redirect it to a file in append mode

access-type Specify an access type

domain Specify an ISP domain

interface Specify an interface

ip Specify an IPv4 address

ipv6 Specify an IPv6 address

mac-address Specify a MAC address

reason-code Specify a reason code

s-vlan Specify a service provider network VLAN

slot Specify the slot number

time Specify a time range

username Specify a username

| Matching output

<cr>

5. Collect the RADIUS packet statistics maintained by the AAA module.

<Sysname> display radius statistics ?

> Redirect it to a file

>> Redirect it to a file in append mode

last-30-minutes Display RADIUS statistics collected during the past 30

minutes

server Specify a RADIUS server

| Matching output

<cr>

6. Collect load statistics for all RADIUS servers.

<Sysname> display radius server-load statistics ?

> Redirect it to a file

>> Redirect it to a file in append mode

| Matching output

<cr>

7. Collect the statistics maintained by the RADIUS module for the online access users in ISP domains.

<Sysname> display domain access-user statistics ?

> Redirect it to a file

>> Redirect it to a file in append mode

| Matching output

<cr>

BRAS service troubleshooting procedures at a glance

Troubleshooting procedures for campus networks

The troubleshooting procedures listed in Table 2 apply to the following router series:

· SR8800-X.

· SR8800-X-S.

· SR8800-F.

· CR16000-F.

· CR16000-M.

Support for the listed procedures differs depending on the router series.

Use Table 2 to quickly locate the troubleshooting procedure of interest by failure type.

Table 2 BRAS service troubleshooting procedures for campus networks

Failure type	Troubleshooting procedures
Troubleshooting user online failures and abnormal offline events	· PPPoE user online failures and abnormal offline events · PPPoE agency user online failures and abnormal offline events · Campus user failures to access the external network on a PPPoE agency network · L2TP user online failures and abnormal offline events · IPoE: ¡ IPoE user online failures and abnormal offline events ¡ IPoE DHCP user online failures and abnormal offline events ¡ IPoE NDRS user online failures and abnormal offline events ¡ IPoE static user online failure or abnormal offline event ¡ IPoE Web user online failure

Failure type

Troubleshooting procedures

Troubleshooting user online failures and abnormal offline events

· PPPoE user online failures and abnormal offline events

· PPPoE agency user online failures and abnormal offline events

· Campus user failures to access the external network on a PPPoE agency network

· L2TP user online failures and abnormal offline events

· IPoE:

¡ IPoE user online failures and abnormal offline events

¡ IPoE DHCP user online failures and abnormal offline events

¡ IPoE NDRS user online failures and abnormal offline events

¡ IPoE static user online failure or abnormal offline event

¡ IPoE Web user online failure

Troubleshooting procedures for carrier networks

Table 3 lists the troubleshooting procedures for the following router series:

· CR16000-F.

· SR8800-F.

Support for the listed procedures differs depending on the router model.

Use Table 3 to quickly locate the troubleshooting procedure of interest by failure type on a telecom network.

Table 3 BRAS service troubleshooting procedures for carrier networks

Failure type

Troubleshooting procedures

Troubleshooting user online failures and abnormal offline events

· PPPoE user online failures and abnormal offline events

· PPPoE agency user online failures and abnormal offline events

· Campus user failures to access the external network on a PPPoE agency network

· L2TP user online failures and abnormal offline events

· IPoE issues:

¡ IPoE user online failures and abnormal offline events

¡ IPoE DHCP user online failures and abnormal offline events

¡ IPoE NDRS user online failures and abnormal offline events

¡ IPoE static user online failure or abnormal offline event

¡ IPoE Web user online failure

Troubleshooting user online failures and abnormal offline events

PPPoE user online failures and abnormal offline events

Symptom

A PPPoE user fails to come online or abnormally goes offline.

Common causes

The following are the common causes of this type of issue:

· A user enters an incorrect username or password.

· The number of consecutive authentication failures of a user exceeds the maximum number allowed, and the user is blocked. The blocking period has not expired.

· The configuration is incorrect. For example, no IP address pool is configured, or the IP addresses in the configured IP address pool are exhausted. As a result, a user cannot obtain an IP address.

· A user owes fees.

Troubleshooting flow

Figure 2 shows the troubleshooting flowchart.

Figure 2 Flowchart for troubleshooting PPPoE user online failures and abnormal offline events

Solution

1. View the PPPoE user online failure reasons.

Execute the display aaa online-fail-record command to display user online failure reasons.

<Sysname> display aaa online-fail-record username aaa

Username: aaa

Domain: test

MAC address: 0010-9400-0007

Access type: PPPoE

Access interface: Ten-GigabitEthernet3/1/1

SVLAN/CVLAN: -/-

IP address: -

IPv6 address: -

Online request time: 2019/09/23 14:57:06

Online failure reason: PPP negotiation terminated.

The Online failure reason field in the command output displays the user online failure reason. You can roughly locate the fault based on the failure reason, which provides guidance for later troubleshooting. Search for the displayed reason in “Appendix A Reasons for user login failures and abnormal logouts” and troubleshoot according to the corresponding solution.

You can resolve the issues caused by some failure reasons (for example, Authentication method error or Local authentication request was rejected) by checking the configuration. If you cannot see the failure records for some failure reasons, proceed with the next step.

2. View the PPPoE user offline reasons.

If you cannot obtain the online failure reasons for a user in step 1, the user might come online successfully and then go offline. In this case, use the display aaa offline-record command to display user offline records.

<Sysname> display aaa offline-record

Total count: 1

Username: jay

Domain: dm1

MAC address: -

Access type: Telnet

Access interface: GigabitEthernet1/0/1

SVLAN/CVLAN: -/-

IP address: 19.19.0.2

IPv6 address: -

Online request time: 2020-01-02 15:20:33

Offline time: 2020-2-28 15:20:56

Offline reason: User request

If a user first comes online successfully and then goes offline, the Offline reason field in the command output displays the offline reason. You can roughly locate the fault based on the failure reason, which provides guidance for later troubleshooting.

Search for the displayed reason in “Appendix A Reasons for user login failures and abnormal logouts” and troubleshoot according to the corresponding solution.

If you cannot use the display aaa offline-record command to obtain the user offline reasons, proceed with the next step.

3. Verify that the PPPoE user settings are correct.

Troubleshoot the settings according to the manuals for BRASs. For example, see tasks at a glance or configuration examples in the corresponding manuals.

¡ If configuration errors exist, correct the configuration and then try to come online again.

¡ If the configuration is correct but the issue persists, proceed with the next step.

4. Identify whether the user is blocked by PPP.

Execute the display ppp chasten user command to identify whether the user is blocked by PPP.

¡ If the user is blocked, redial after the remaining blocking time expires according to the command output.

¡ If the user is not blocked, proceed with the next step.

5. Enable the service tracing messages.

Execute the trace access-user command to enable the service tracing feature for users to test user online events. After the user online process is completed, view the service tracing messages. If the device does not receive PADI or PADR packets, identify whether the Layer 2 network is reachable, the port state is normal, the access type is Layer 2, the authentication method contains PPP, and the interface is bound to a virtual-template interface.

6. Identify whether the user is blocked by PPPoE.

Execute the display pppoe-server chasten user command to identify whether the user is blocked by PPPoE.

¡ If the user is blocked, redial after the remaining blocking time expires according to the command output.

¡ If the user is not blocked, proceed with the next step.

7. Check the device failures.

If you cannot view any service tracing message for the user, check the following configurations:

¡ Make sure the physical connections of the device are correct.

¡ Make sure the configuration on the device is correct.

¡ Make sure the Layer 2 network configuration is correct.

¡ Make sure packets can reach the device.

In probe view, execute the display hardware internal rxtx packet statistic command to view statistics of packets received/sent by the device driver. Identify whether the user packets are sent to the BRAS.

<Sysname> system-view

[Sysname-probe] probe

[Sysname-probe] display hardware internal rxtx packet statistic slot 3 cpu 0

Net port packet loss count:

code counter

Rx packets statistic:

counter success rate

NET ->RXTX : 171883335 171554546 342 pps

Cpu code input list:(Mgment to L1 queue)

code counter success(whitelist/normal)

5 14475 14475(0/14475)

6 2308 2308(0/2308)

17 262 262(0/262)

26 1013133 986703(0/986703)

30 6014064 6014064(0/6014064)

35 282 282(0/282)

37 79280 79280(0/79280)

43 2423 2423(0/2423)

44 44438 44438(0/44438)

45 1181 1181(0/1181)

49 60638 60638(0/60638)

50 25 25(0/25)

51 60361 60361(0/60361)

52 496 496(0/496)

53 115767 115767(115726/41)

54 83228 83228(83228/0)

61 191235 191235(0/191235)

77 12007 11988(0/11988)

99 6041569 6041569(0/6041569)

106 30 30(0/30)

149 158129148 157826808(0/157826808)

175 16985 16985(16979/6)

Callback function packets statistic:

total(r) success(r) total(c) success(c)

MACL: 0 0 0 0

NATL: 0 0 0 0

BFD: 0 0 0 0

(null): 0 0 0 0

Task input pkt statistics:

Task name total success

Main Task : 165540452 165540452

Icmp Task : 30 30

Cpu code input list:(L2 queue to platform)

code counter success drop rate

5 14475 14475 0 0

6 2308 2308 0 0

17 262 262 0 0

26 986703 986703 0 1

35 282 282 0 0

37 79280 79280 0 0

43 2423 2423 0 0

44 44438 44438 0 0

45 1181 1181 0 0

49 60638 60638 0 0

50 25 25 0 0

51 60361 60361 0 0

52 496 496 0 0

53 115767 115767 0 0

54 83228 83228 0 0

61 191235 191235 0 0

77 11988 11988 0 0

99 6041569 6041569 0 12

106 30 30 0 0

149 157826808 157826808 0 314

175 16985 16985 0 0

Cpu code to protocol:

5 ARP_REQ_LOCAL

6 ARP_REL

17 ARP_REQ

26 PPPOE

30 DIAG

35 ND_NA

37 LLDP,CDP

43 ND_NS

44 ND_RS

45 ND_RA

49 OSPF_HELLO,OSPF_LSU,OSPF_LSACK

50 OSPF_DD,OSPF_LSR

51 OSPFV3_HELLO,OSPFV3_LSU,OSPFV3_LSACK

52 OSPFV3_DD,OSPFV3_LSR

53 LDP_HELLO

54 LDP_NOTIF,LDP_INIT,LDP_KPALV,LDP_ADDR,LDP_LABEL

61 DHCP_IPOE,DHCP_SNOOPING,DHCP,DHCPv6_RELAY,DHCPv6_RELS,DHCPv6_SERV

77 IP_SUBNET

99 PPPOE_PPP

106 ICMP,ICMPV6

149 L2TP

175 APP_TELNET

Debug packets statistic:

counter counter rate

NET->RXTX->SERVICE: 0 0 0 pps

SERVICE->RXTX->NET: 0 0 0 pps

failed

MbufTrSend: 0

FoundIfindex: 0

SaveCoreSta: 0

MainCoreSta: 0

TxFailedSta: 0

The 26 and 99 fields represent PPPoE and PPPoE_PPPP, respectively. If the received packet counts for 26 and 99 increase, it means that the device has received PPP/PPPoE packets and sent them to the platform. You can use debugging for the forwarding function to check the layer on which packets are dropped step by step. If the counts do not increase, execute the display hardware internal np pktcnt drop command to identify whether the driver has dropped packet count.

<Sysname> system-view

[Sysname-probe] probe

[Sysname-probe] display hardware internal np pktcnt drop slot 3 (the command for viewing the packet count varies by device model)

Current Mcode Type: SIRIUS_RELEASE

The NP 0 is Both NP

Drop packet statistics

32B7 116497 TOPparse total discarded pkts

350F 916677 TOPresolve total discarded pkts

51A 66 PRS Ingress route interface deny L2 forward

56B 384 PRS Ingress Route interface deny L2 forward

63C 403633 RSV Ingress ARP packet FTN or BROADCAST table no ma

tch

63E 372789 RSV Ingress PROTOCOL_MAC and BROADCAST table no mat

641 161878 RSV Ingress PROTOCOL_MAC.THB is set, but BROADCAST

table no match

645 149489 RSV Ingress multicast, MULTICAST.DROP is set

646 144150 RSV Ingress multicast, match MULTICAST default entr

y, but BROADCAST table no match

663 4 RSV Ingress broadcast packets from route port, PROT

OCOL_PORT table no match

- If the dropped packet count keeps increasing, analyze the possible issues according to the packet drop reasons.

- If the dropped packet count does not increase and the number of packets sent to the CPU also does not increase, it means that packets are not successfully sent to the BRAS. In this case, collect the failure information and contact Technical Support.

Only if the preceding configurations are all correct, you can use the service tracing function to see the tracing messages.

If you determine that the user online failure reason is incorrect configuration, check the local configuration according to the tracing messages.

¡ For a RADIUS authentication user, you must identify whether the RADIUS server is correctly configured and the RADIUS server state is normal.

¡ For a local authentication user, identify whether the local account configuration is correct, and the number of access users is not limited.

8. Identify whether the LCP negotiation succeeds.

You can obtain the negotiation packet statistics on the BRAS and client separately (on the client, you can capture the negotiation packets). In this way, you can quickly locate what causes the LCP negotiation failure: the device, the client, or the cooperation between devices.

<Sysname> display ppp packet statistics

PPP packet statistics in slot 97:

-----------------------------------LCP--------------------------------------

SEND_LCP_CON_REQ : 6185 RECV_LCP_CON_REQ : 6177

SEND_LCP_CON_NAK : 0 RECV_LCP_CON_NAK : 0

SEND_LCP_CON_REJ : 0 RECV_LCP_CON_REJ : 0

SEND_LCP_CON_ACK : 6177 RECV_LCP_CON_ACK : 6000

SEND_LCP_CODE_REJ : 0 RECV_LCP_CODE_REJ : 0

SEND_LCP_PROT_REJ : 0 RECV_LCP_PROT_REJ : 0

SEND_LCP_TERM_REQ : 0 RECV_LCP_TERM_REQ : 0

SEND_LCP_TERM_ACK : 0 RECV_LCP_TERM_ACK : 0

SEND_LCP_ECHO_REQ : 0 RECV_LCP_ECHO_REQ : 0

SEND_LCP_ECHO_REP : 0 RECV_LCP_ECHO_REP : 0

SEND_LCP_FAIL : 0 SEND_LCP_CON_REQ_RETRAN : 185

-----------------------------------IPCP-------------------------------------

SEND_IPCP_CON_REQ : 0 RECV_IPCP_CON_REQ : 0

SEND_IPCP_CON_NAK : 0 RECV_IPCP_CON_NAK : 0

SEND_IPCP_CON_REJ : 0 RECV_IPCP_CON_REJ : 0

SEND_IPCP_CON_ACK : 0 RECV_IPCP_CON_ACK : 0

SEND_IPCP_CODE_REJ : 0 RECV_IPCP_CODE_REJ : 0

SEND_IPCP_PROT_REJ : 0 RECV_IPCP_PROT_REJ : 0

SEND_IPCP_TERM_REQ : 0 RECV_IPCP_TERM_REQ : 0

SEND_IPCP_TERM_ACK : 0 RECV_IPCP_TERM_ACK : 0

SEND_IPCP_FAIL : 0

-----------------------------------IPV6CP-----------------------------------

SEND_IPV6CP_CON_REQ : 0 RECV_IPV6CP_CON_REQ : 0

SEND_IPV6CP_CON_NAK : 0 RECV_IPV6CP_CON_NAK : 0

SEND_IPV6CP_CON_REJ : 0 RECV_IPV6CP_CON_REJ : 0

SEND_IPV6CP_CON_ACK : 0 RECV_IPV6CP_CON_ACK : 0

SEND_IPV6CP_CODE_REJ : 0 RECV_IPV6CP_CODE_REJ : 0

SEND_IPV6CP_PROT_REJ : 0 RECV_IPV6CP_PROT_REJ : 0

SEND_IPV6CP_TERM_REQ : 0 RECV_IPV6CP_TERM_REQ : 0

SEND_IPV6CP_TERM_ACK : 0 RECV_IPV6CP_TERM_ACK : 0

SEND_IPV6CP_FAIL : 0

-----------------------------------OSICP------------------------------------

SEND_OSICP_CON_REQ : 0 RECV_OSICP_CON_REQ : 0

SEND_OSICP_CON_NAK : 0 RECV_OSICP_CON_NAK : 0

SEND_OSICP_CON_REJ : 0 RECV_OSICP_CON_REJ : 0

SEND_OSICP_CON_ACK : 0 RECV_OSICP_CON_ACK : 0

SEND_OSICP_CODE_REJ : 0 RECV_OSICP_CODE_REJ : 0

SEND_OSICP_PROT_REJ : 0 RECV_OSICP_PROT_REJ : 0

SEND_OSICP_TERM_REQ : 0 RECV_OSICP_TERM_REQ : 0

SEND_OSICP_TERM_ACK : 0 RECV_OSICP_TERM_ACK : 0

SEND_OSICP_FAIL : 0

-----------------------------------MPLSCP-----------------------------------

SEND_MPLSCP_CON_REQ : 0 RECV_MPLSCP_CON_REQ : 0

SEND_MPLSCP_CON_NAK : 0 RECV_MPLSCP_CON_NAK : 0

SEND_MPLSCP_CON_REJ : 0 RECV_MPLSCP_CON_REJ : 0

SEND_MPLSCP_CON_ACK : 0 RECV_MPLSCP_CON_ACK : 0

SEND_MPLSCP_CODE_REJ : 0 RECV_MPLSCP_CODE_REJ : 0

SEND_MPLSCP_PROT_REJ : 0 RECV_MPLSCP_PROT_REJ : 0

SEND_MPLSCP_TERM_REQ : 0 RECV_MPLSCP_TERM_REQ : 0

SEND_MPLSCP_TERM_ACK : 0 RECV_MPLSCP_TERM_ACK : 0

SEND_MPLSCP_FAIL : 0

-----------------------------------AUTH-------------------------------------

SEND_PAP_AUTH_REQ : 0 RECV_PAP_AUTH_REQ : 6000

SEND_PAP_AUTH_ACK : 0 RECV_PAP_AUTH_ACK : 0

SEND_PAP_AUTH_NAK : 0 RECV_PAP_AUTH_NAK : 0

SEND_CHAP_AUTH_CHALLENGE: 0 RECV_CHAP_AUTH_CHALLENGE: 0

SEND_CHAP_AUTH_RESPONSE : 0 RECV_CHAP_AUTH_RESPONSE : 0

SEND_CHAP_AUTH_ACK : 0 RECV_CHAP_AUTH_ACK : 0

SEND_CHAP_AUTH_NAK : 0 RECV_CHAP_AUTH_NAK : 0

SEND_PAP_AUTH_FAIL : 0 SEND_CHAP_AUTH_FAIL : 0

Common symptoms include:

¡ During the LCP negotiation process of a PPPoE client, the PPPoE client sends config-requests, and the device responds and sends config-nak/config-reject packets. In this case, the client must modify the attribute values in the corresponding config-requests according to the replies from the device. However, the client might always not modify the negotiation attributes. As a result, the negotiation fails. In this case, you can capture packets or execute the debugging ppp all command to enable debugging to check the attributes that cause the negotiation failure. According to these attributes, you can check the corresponding configuration and make sure the configuration is correct. If the issue persists, contact Technical Support.

¡ The device is configured with CHAP authentication. However, the client supports only PAP authentication. Therefore, LCP negotiation always fails. In this case, modify CHAP authentication to PAP authentication on the device.

9. Identify whether authentication succeeds.

¡ For local authentication, the authentication failure reason might be:

- The local account does not exist.

- The authentication domain is not activated.

- The account is not activated.

- The account type is inconsistent.

- The access is limited.

¡ For RADIUS authentication, the authentication failure reason might be the device does not receive RADIUS replies or RADIUS authentication is rejected.

10. Identify whether the NCP negotiation succeeds.

Typically, NCP performs only address negotiation in PPPoE. Therefore, NCP negotiation failure means address negotiation failure. You can check the configuration according to the locally allocated address, RADIUS allocated address, and DHCP allocated address.

11. Identify whether accounting is normal.

If the user still cannot come online in this case, accounting might fail. The most common reason is that accounting fails to start. In this case, you must identify whether the device and AAA server can reach each other at Layer 3 and whether the AAA server’s accounting function is configured correctly.

12. If the issue persists, collect the following information and contact Technical Support:

¡ Results of each step.

¡ The configuration file, log messages, and alarm messages.

PPPoE agency user online failures and abnormal offline events

Symptom

A PPPoE agency user fails to come online or abnormally goes offline.

Common causes

The following are the common causes of this type of issue:

· The campus BRAS user corresponding to a PPPoE agency user fails to come online or abnormally goes offline.

· The PPPoE agency configuration is incorrect. For example:

¡ The interface connecting the campus BRAS to the service provider BRAS is not enabled with PPPoE agency. As a result, a PPPoE agency user fails to come online.

¡ The PPPoE agency group name configured for the PPPoE agency interface on the campus BRAS is different from the PPPoE agency group name deployed through COA messages by the campus AAA server. As a result, a PPPoE agency user fails to come online.

¡ The undo pppoe-agency forward command is executed in user group view of a campus BRAS user to delete the PPPoE agency forwarding policy. As a result, the corresponding PPPoE agency user goes offline.

¡ The COA messages are used on the campus AAA server to modify the user-group attribute of a campus BRAS user to a user group that does not support PPPoE agency, or the undo user-group command is executed in system view on the campus BRAS to delete the user group of a campus BRAS user. As a result, the corresponding PPPoE agency user goes offline.

· The link between the campus BRAS and the service provider BRAS fails. For example, the PPPoE agency interface is down.

· The campus AAA server forcibly logs out a PPPoE agency user.

· A PPPoE agency user is forcibly logged out by the service provider because the user traffic is exhausted or the user owes fees.

Troubleshooting flow

Figure 3 shows the troubleshooting flowchart.

Figure 3 Flowchart for troubleshooting PPPoE agency user online failures and abnormal offline events

Solution

1. Identify whether the campus BRAS user corresponding to a PPPoE agency user has come online successfully.

Execute the display access-user command in any view on the campus BRAS to identify whether the campus BRAS user corresponding to a PPPoE agency user has come online successfully.

¡ If the campus BRAS user fails to come online or abnormally goes offline after coming online, resolve the issue according to the access authentication method (IPoE or PPPoE) used by the campus BRAS user and the online failure and abnormal offline failure troubleshooting flow for the user type in “Troubleshooting user online failures and abnormal offline events.”

¡ If the campus BRAS user comes online normally, proceed with the next step.

2. View the PPPoE agency user online failure reasons.

Execute the display aaa online-fail-record command in any view on the campus BRAS to identify the PPPoE agency user online failure reasons.

<Sysname> display aaa online-fail-record username aaa

Username: aaa

Domain: test

MAC address: 0010-9400-0007

Access type: PPPoEA

Access interface: Ten-GigabitEthernet3/1/1

SVLAN/CVLAN: -/-

IP address: -

IPv6 address: -

Online request time: 2022/04/23 14:57:06

Online failure reason: Disabled PPPoE agency.

The Online failure reason field in the command output displays the user online failure reason. You can roughly locate the fault based on the failure reason. Search for the displayed reason in “Appendix A Reasons for user login failures and abnormal logouts” and troubleshoot according to the corresponding solution.

If you cannot see the failure records for some failure reasons, proceed with the next step.

3. View the PPPoE agency user offline reasons.

If you cannot obtain the online failure reasons for a user in the display aaa online-fail-record command output, the user might come online successfully and then go offline. In this case, use the display aaa offline-record command to display user offline records.

<Sysname> display aaa offline-record

Total count: 1

Username: jay

Domain: dm1

MAC address: -

Access type: Telnet

Access interface: GigabitEthernet1/0/1

SVLAN/CVLAN: -/-

IP address: 19.19.0.2

IPv6 address: -

Online request time: 2020-01-02 15:20:33

Offline time: 2020-2-28 15:20:56

Offline reason: User request

Search for the displayed reason in “Appendix A Reasons for user login failures and abnormal logouts” and troubleshoot according to the corresponding solution.

If you cannot use the display aaa offline-record command to obtain the user offline reasons, proceed with the next step.

4. Troubleshoot the issue based on the RADIUS debugging information.

If you cannot obtain the failure reasons in the preceding steps, execute the debugging radius all command in user view on the campus BRAS to enable debugging for RADIUS. Troubleshoot the issue according to the Reply-Message field in the debugging information.

The Reply-Message field displays the PPPoE agency failure reason. Search for the displayed reason in “Appendix A Reasons for user login failures and abnormal logouts” and troubleshoot according to the corresponding solution.

5. Identify whether the campus BRAS has received agency requests from the campus AAA server.

Execute the display radius statistics command in any view on the campus BRAS to view statistics of the PPPoE agency packets between the campus BRAS and campus AAA server.

¡ If the value for the COA requests field is 0 (or the value does not change when you view this field multiple times), the campus BRAS does not receive agency requests from the campus AAA server. In this case, verify that the PPPoE agency user settings on the campus AAA server are correct to resolve the issue that the campus AAA server does not send agency requests.

¡ If the value for the COA requests field is not 0 and changes when you view this field multiple times, proceed with the next step.

6. Identify whether the campus BRAS can provide the PPPoE agency service for campus users.

Execute the display pppoe-agency packet statistics command in any view on the campus BRAS to view the negotiation packet statistics for PPPoE agency.

¡ If the value for the SEND_PADI_PKT field is 0 (or the value does not change when you view this field multiple times), the campus BRAS user does not trigger the agency process after coming online. Perform the following checks according to the PPPoE configuration guide to resolve the issue that the agency process cannot be triggered.

- Make sure the interface connecting the campus BRAS to the service provider BRAS is enabled with PPPoE agency.

- Make sure the agency group name that the campus AAA server assigns to campus BRAS user through COA messages can find the corresponding agency interface on the BRAS and the agency interface is up.

- Make sure a correct PPPoE agency forwarding policy is configured in user group view for the campus BRAS user.

¡ The campus BRAS user triggers the PPPoE agency process after coming online, but the campus BRAS does not receive the PPPoE protocol packets replied by the service provider BRAS if the following conditions exist:

- The value for the SEND_PADI_PKT field is not 0 and the value changes when you view this field multiple times.

- The value for the RECV_PADO_PKT field is 0 (or the value does not change when you view this field multiple times),

Perform the following checks according to the PPPoE configuration guide to resolve the issue that the campus BRAS cannot receive replies from the service provider BRAS.

- Make sure the interface connecting the service provider BRAS to the campus BRAS is enabled with the PPPoE server feature.

- Make sure the interface connecting the service provider BRAS to the campus BRAS is up.

¡ If the campus BRAS can send and receive PPPoE negotiation packets for PPPoE agency normally, proceed with the next step.

7. Troubleshoot on the service provider BRAS.

For the service provider BRAS, a campus PPPoE agency user is a common PPPoE user. On the service provider BRAS, troubleshoot this issue.

If the issue persists after troubleshooting, proceed with the next step.

8. If the issue persists, collect the following information and contact Technical Support:

¡ Results of each step.

¡ The configuration file, log messages, and alarm messages.

Related alarm and log messages

Alarm messages

N/A

Log messages

N/A

Campus user failures to access the external network on a PPPoE agency network

Symptom

On a PPPoE agency network, after a campus user that has opened a service provider agency account comes online through IPoE or PPPoE, the user can access only the campus network but cannot access the external network.

Common causes

The following are the common causes of this type of issue:

· The PPPoE agency user corresponding to a campus BRAS user is not online.

· The PPPoE agency forwarding policy configuration is incorrect on the campus BRAS.

· The PPPoE agency forwarding policy configuration is correct on the campus BRAS, but the ACL in the policy fails to be applied.

· The service provider BRAS fails.

Troubleshooting flow

Figure 4 shows the troubleshooting flowchart.

Figure 4 Flowchart for troubleshooting campus user failures to access the external network on a PPPoE agency network

Solution

1. Identify whether the PPPoE agency user corresponding to a campus BRAS user has come online successfully.

Execute the display access-user command in any view on the campus BRAS to identify whether the PPPoE agency user corresponding to the campus BRAS user has come online successfully.

¡ If the PPPoE agency user has not come online, troubleshoot this issue as described in “PPPoE user online failures and abnormal offline events.”

¡ If the PPPoE agency user comes online normally, proceed with the next step.

2. Identify whether the PPPoE agency forwarding policy configuration is correct.

Identify whether a correct ACL is specified in the pppoe-agency forward { ipv4 | ipv6 } acl { acl-number | name acl-name } command in the user group of the agency campus BRAS user on the campus BRAS.

¡ If the ACL is configured incorrectly (for example, the ACL specified in the PPPoE agency forwarding policy does not allow specifying the user-group parameter but the user-group parameter is specified in the ACL), correct the configuration.

¡ If the ACL configuration is correct, proceed with the next step.

3. Identify whether the ACL specified in the PPPoE agency forwarding policy is applied successfully.

Execute the display pppoe-agency { ipv4 | ipv6 } acl statistics command in any view on the campus BRAS to identify whether the ACL specified in the PPPoE agency forwarding policy is successfully applied.

¡ If the ACL fails to be applied, perform one of the following tasks according to the failure reason:

- If the failure reason is Hardware-count (Failed), contact Technical Support.

- If the failure reason is Hardware-count(Not enough resources to complete the operation.), execute the display qos-acl resource command in system view to collect the current ACL usage and contact Technical Support.

- If the failure reason is Hardware-count(The operation is not supported.), identify whether the software and hardware requirements of the device are met according to the product manuals. For example, identify whether the card hosting the access interface of the campus BRAS supports PPPoE agency.

¡ If the ACL is applied successfully, proceed with the next step.

4. Troubleshoot on the service provider BRAS

For the service provider BRAS, a campus PPPoE agency user is a common PPPoE user. On the service provider BRAS, troubleshoot this issue.

If the issue persists after troubleshooting, proceed with the next step.

5. If the issue persists, collect the following information and contact Technical Support:

¡ Results of each step.

¡ The configuration file, log messages, and alarm messages.

Related alarm and log messages

Alarm messages

N/A

Log messages

N/A

L2TP user online failures and abnormal offline events

Symptom

An L2TP user fails to come online or abnormally goes offline.

Common causes

The following the common causes of this type of issue:

· The LAC and the LNS cannot reach each other at Layer 3.

· The service modules that establish the L2TP tunnel between the LAC and the LNS do not support L2TP.

· The LAC or the LNS is not enabled with L2TP.

· The L2TP group settings on the LAC and the LNS do not match.

· The tunnel authentication methods or authentication passwords on the LAC and the LNS are inconsistent.

· PPPoE access fails on the LAC.

· The PPP authentication methods on the LAC and the LNS are inconsistent.

· An LNS is configured with an L2TP group in LAC mode and acts as a Layer 2 tunnel switch (LTS).

· The IP address pool is configured incorrectly, and the L2TP user is not assigned an IP address.

Troubleshooting flow

Figure 5 shows the troubleshooting flowchart.

Figure 5 Flowchart for troubleshooting L2TP user online failures and abnormal offline events

Solution

1. Check whether PPPoE access services are correct on the LAC.

For more information, see "PPPoE user online failures and abnormal offline events."

If PPPoE access services are correct, proceed to the next step.

2. Identify the online failure reason and offline reason on the LNS.

¡ Use the display aaa online-fail-record command to identify the online failure reason. The Online failure reason field in the command output displays the user online failure reason. You can roughly locate the fault based on the failure reason, which provides guidance for later troubleshooting.

¡ If you cannot obtain the online failure reasons for a user in step 1, the user might come online successfully and then go offline. In this case, use the display aaa offline-record command to display user offline records. If you cannot use the display aaa offline-record command to obtain the user offline reasons, proceed to the next step.

3. Check whether the LNS can be pinged from the LAC.

¡ If yes, proceed to the next step.

¡ If not, solve the connectivity issue.

4. Use the display device command on the LAC and the LNS to check whether the service modules used to establish the L2TP tunnel support L2TP.

¡ If yes, proceed to the next step.

¡ If not, evaluate whether the service modules can be replaced. If the issue persists after the service modules are replaced, proceed to the next step.

5. Use the display current-configuration command on the LAC and the LNS to check whether L2TP is enabled.

¡ If yes (the l2tp enable field is displayed), proceed to the next step.

¡ If not (the l2tp enable field is not displayed), use the l2tp enable command to enable L2TP. If the issue persists after L2TP is enabled, proceed to the next step.

6. Check whether the L2TP parameters in the L2TP group are configured correctly on the LAC and the LNS.

¡ On the LAC, use the display l2tp-group verbose command to check whether the LNS IP address (LNS IP field) is the same as the actual LNS IP address. If not, use the lns-ip command to change the LNS IP address.

¡ On the LNS, use the display l2tp-group verbose command to check the following items:

- Verify that the remote tunnel name is the same as the tunnel name configured on the LAC.

- Verify that the local tunnel IP address is the same as the IP address configured by the lns-ip command on the LAC.

If the issue persists after all L2TP parameters in the L2TP group are configured correctly, proceed to the next step.

7. Use the display l2tp-group verbose command on the LAC and the LNS to check whether the tunnel authentication settings are the same.

¡ Check whether the tunnel authentication states (Tunnel auth field) on the LAC and the LNS are the same. If not, use the tunnel authentication command to change the tunnel authentication status on the LAC or the LNS.

¡ If both the LAC and the LNS are enabled with tunnel authentication, verify that the tunnel authentication passwords configured on the LAC and the LNS are the same. To change the tunnel authentication password, use the tunnel password command.

¡ If the issue persists after the authentication settings are configured correctly, proceed to the next step.

8. Use the display current-configuration interface virtual-template command on the LAC and the LNS to check whether the PPP authentication methods (ppp authentication-mode field) are the same.

¡ If not, use the ppp authentication-mode command in VT interface view to configure the PPP authentication method.

¡ If yes, proceed to the next step.

9. Check whether an LAC-mode L2TP group has the same user configuration as an L2TP group configured on the LAC.

¡ If not, proceed to the next step.

¡ If yes, execute the undo user command to delete the configuration. If the issue persists after the configuration is deleted, proceed to the next step.

10. Check whether the user has been assigned an IP address.

¡ If not, configure a correct address pool on the LNS.

¡ If yes, proceed to the next step.

11. If the issue persists, collect the following information and contact Technical Support:

¡ Results of each step.

¡ The configuration file, log messages, and alarm messages.

IPoE user online failures and abnormal offline events

This section describes the common troubleshooting method for IPoE users. For the more specific troubleshooting methods for IPoE DHCP users, IPoE NDRS users, IPoE static users, and IPoE Web users, see their respective sections.

Symptom

An IPoE user fails to come online or abnormally goes offline.

Common causes

The following the common causes of this type of issue:

· The authentication domain is configured incorrectly, which leads to authentication failure.

· The IP address pool or DHCP server is configured incorrectly, which causes the user to fail to obtain an IP address.

Troubleshooting flow

Figure 6 shows the troubleshooting flowchart.

Figure 6 Flowchart for troubleshooting IPoE user online failures and abnormal offline events

Solution

1. Use the display aaa online-fail-record command to identify the online failure reason.

<Sysname> display aaa online-fail-record username aaa

Username: aaa

Domain: test

MAC address: 0010-9400-0007

Access type: IPoE

Access interface: Ten-GigabitEthernet3/1/1

SVLAN/CVLAN: -/-

IP address: -

IPv6 address: -

Online request time: 2019/09/23 14:57:06

Online failure reason: DHCP with server no response

The Online failure reason field in the command output displays the user online failure reason. You can roughly locate the fault based on the failure reason, which provides guidance for later troubleshooting. Search for the displayed reason in "Appendix A Reasons for user login failures and abnormal logouts" and troubleshoot according to the corresponding solution.

2. Use the display aaa offline-record command to identify the offline reason.

Search for the displayed reason in "Appendix A Reasons for user login failures and abnormal logouts" and troubleshoot according to the corresponding solution.

If you cannot use the display aaa offline-record command to obtain the user offline reasons, proceed with the next step.

3. Check whether the user has passed authentication.

¡ If not, examine the authentication domain configuration based on the IPoE authentication method.

¡ If yes, proceed to the next step.

4. Check whether the user has obtained an IP address.

¡ If not, examine the IP address pool or DHCP server configuration (for example, whether the DHCP service is enabled).

¡ If yes, proceed to the next step.

5. Execute the trace access-user command in system view to enable service tracing to troubleshoot the issue.

6. If the issue persists, collect the following information and contact Technical Support:

¡ Results of each step.

¡ The configuration file, log messages, and alarm messages.

IPoE DHCP user online failures and abnormal offline events

Symptom

An IPoE DHCP user fails to come online or abnormally goes offline.

Common causes

The following the common causes of this type of issue:

· Configuration errors exist. For example, the managed address configuration flag (M) is set to 0 for DHCPv6 users on an interface.

· User authentication fails.

· The user is logged out after coming online due to reasons such as timeout.

· The user is blocked.

· No DHCP messages are received.

Troubleshooting flow

Figure 7 shows the troubleshooting flowchart.

Figure 7 Flowchart for troubleshooting IPoE DHCP user online failures and abnormal offline events

Solution

1. Use the display aaa online-fail-record command to identify the online failure reason.

<Sysname> display aaa online-fail-record

Total count: 108

Username: 001094500021

Domain: dm1

MAC address: 0010-9450-0021

Access type: IPoE

Access UP ID: 1354

Access interface: XGE3/1/1

SVLAN/CVLAN: -/-

IP address: -

IPv6 address: -

Online request time: 2021/08/15 07:38:15

Online failure reason: DHCP with server no response

The Online failure reason field in the command output displays the user online failure reason. You can roughly locate the fault based on the failure reason, which provides guidance for later troubleshooting. Search for the displayed reason in "Appendix A Reasons for user login failures and abnormal logouts" and troubleshoot according to the corresponding solution.

2. Use the display aaa offline-record command to identify the offline reason.

<Sysname> display aaa offline-record

Total count: 4

Username: 001094500021

Domain: dm1

MAC address: 0010-9450-0021

Access type: IPoE

Access UP ID: 1354

Access interface: XGE3/1/1

SVLAN/CVLAN: -/-

IP address: 9.0.3.1

IPv6 address: -

Online request time: 2021/08/15 08:05:17

Offline time: 2021/08/15 08:09:08

Offline reason: DHCP release

Search for the displayed reason in "Appendix A Reasons for user login failures and abnormal logouts" and troubleshoot according to the corresponding solution.

If you cannot use the display aaa offline-record command to obtain the user offline reasons, proceed with the next step.

If the offline reason cannot be identified, proceed to the next step.

3. Check whether the IPoE DHCP settings are correct.

Troubleshoot the settings according to the manuals for BRASs. For example, see tasks at a glance or configuration examples in the corresponding manuals.

¡ If configuration errors exist, correct the configuration and then try to come online again.

¡ If the configuration is correct but the issue persists, proceed to the next step.

4. Check whether the user has been blocked.

¡ Use the display ip subscriber chasten user quiet command to check whether the user has been blocked by the quiet timer. If yes, wait for the quiet timer to expire.

¡ Use the display dhcp interface-rate-suppression command to check whether the user has been suppressed by interface-based DHCP attack suppression. If the State field is Restrain, the user is suppressed. In this case, use the interface-rate-suppression threshold command to modify the DHCP packet rate threshold.

If the user is not blocked, proceed to the next step.

5. Use the display dhcp-access packet statistics command to check whether the DHCP module receives packets.

<Sysname> display dhcp-access packet statistics

Received packets

Received from clients : 32

DHCPDISCOVER : 24

DHCPREQUEST : 4

DHCPDECLINE : 0

DHCPRELEASE : 4

DHCPINFORM : 0

Received from servers : 8

DHCPOFFER : 4

DHCPACK : 4

DHCPNAK : 0

Sent packets

Send to clients : 8

DHCPOFFER : 4

DHCPACK : 4

DHCPNAK : 0

Send to servers : 148135

DHCPDISCOVER : 148127

DHCPREQUEST : 4

DHCPDECLINE : 0

DHCPRELEASE : 4

In the sample output, the count of the DHCPDISCOVER field increases, which indicates that the device receives DHCP-DISCOVER messages. In this case, execute the following commands and collect service tracing messages.

¡ Execute the trace access-user command to enable service tracing.

¡ Execute the debugging dhcp server packet command to enable DHCP protocol message debugging.

¡ Execute the terminal debugging and terminal monitor commands to enable output of debugging messages to the current terminal and enable log output to the current terminal.

If the count of the DHCPDISCOVER field does not increase, execute the debugging ip subscriber all command to enable IPoE debugging. If the IPoE module receives DHCP-DISCOVER messages but drops them, analyze the reason according to the debug information. If the IPoE module does not receive DHCP-DISCOVER messages, proceed to the next step.

6. Check whether the device receives user messages.

<Sysname> system-view

[Sysname-probe] probe

[Sysname-probe] display hardware internal rxtx packet statistic slot 3 cpu 0

Net port packet loss count:

code counter

Rx packets statistic:

counter success rate

NET ->RXTX : 3177780 3177780 9 pps

Cpu code input list:(Mgment to L1 queue)

code counter success(whitelist/normal)

5 2057 2057(0/2057)

6 2077 2077(0/2077)

17 98 98(0/98)

18 48 48(0/48)

30 2091197 2091197(0/2091197)

35 573 573(0/573)

43 565 565(0/565)

45 4327 4327(0/4327)

49 79488 79488(0/79488)

50 85 85(0/85)

53 69830 69830(69823/7)

54 46567 46567(46566/1)

57 161707 161707(0/161707)

59 13052 13052(13044/8)

60 26280 26280(13953/12327)

61 30 30(0/30)

153 593518 593518(593513/5)

185 4354 4354(0/4354)

194 81927 81927(0/81927)

Callback function packets statistic:

total(r) success(r) total(c) success(c)

MACL: 0 0 0 0

NATL: 0 0 0 0

BFD: 0 0 0 0

(null): 0 0 0 0

Task input pkt statistics:

Task name total success

Main Task : 1086583 1086583

Icmp Task : 0 0

Cpu code input list:(L2 queue to platform)

code counter success drop rate

5 2057 2057 0 0

6 2077 2077 0 0

17 98 98 0 0

18 48 48 0 0

35 573 573 0 0

43 565 565 0 0

45 4327 4327 0 0

49 79488 79488 0 0

50 85 85 0 0

53 69830 69830 0 0

54 46567 46567 0 0

57 161707 161707 0 0

59 13052 13052 0 0

60 26280 26280 0 0

61 30 30 0 0

153 593518 593518 0 1

185 4354 4354 0 0

194 81927 81927 0 0

Cpu code to protocol:

5 ARP_REQ_LOCAL

6 ARP_REL

17 ARP_REQ

18 ARP_REQ_PROXY

30 DIAG

35 ND_NA

43 ND_NS

45 ND_RA

49 OSPF_HELLO,OSPF_LSU,OSPF_LSACK

50 OSPF_DD,OSPF_LSR

53 LDP_HELLO

54 LDP_NOTIF,LDP_INIT,LDP_KPALV,LDP_ADDR,LDP_LABEL

57 ISIS

59 BGP

60 BGP4P_IPV6

61 DHCP_IPOE,DHCP_SNOOPING,DHCP,DHCPv6_RELAY,DHCPv6_RELS,DHCPv6_SERV

153 IP_VSRP

185 VXLAN_GPE

194 CUSP

Debug packets statistic:

counter counter rate

NET->RXTX->SERVICE: 0 0 0 pps

SERVICE->RXTX->NET: 0 0 0 pps

failed

MbufTrSend: 0

FoundIfindex: 0

SaveCoreSta: 0

MainCoreSta: 0

TxFailedSta: 0

The 61 field represents DHCP_IPOE, DHCP_SNOOPING, and DHCP. If the received packet count for 61 increases, it means that the device has received DHCP messages and sent them to the platform. You can use debugging for the forwarding function to identify the layer on which packets are dropped step by step. If the count does not increase, execute the display hardware internal np pktcnt drop command to identify whether the driver has packet drop count.

<Sysname> system-view

[Sysname-probe] probe

[Sysname-probe] display hardware internal np pktcnt drop slot 3 (the command for viewing the packet count varies by device model)

Current Mcode Type: SIRIUS_RELEASE

The NP 0 is Both NP

Drop packet statistics

32B7 116497 TOPparse total discarded pkts

350F 916677 TOPresolve total discarded pkts

51A 66 PRS Ingress route interface deny L2 forward

56B 384 PRS Ingress Route interface deny L2 forward

63C 403633 RSV Ingress ARP packet FTN or BROADCAST table no ma

tch

63E 372789 RSV Ingress PROTOCOL_MAC and BROADCAST table no mat

641 161878 RSV Ingress PROTOCOL_MAC.THB is set, but BROADCAST

table no match

645 149489 RSV Ingress multicast, MULTICAST.DROP is set

646 144150 RSV Ingress multicast, match MULTICAST default entr

y, but BROADCAST table no match

663 4 RSV Ingress broadcast packets from route port, PROT

OCOL_PORT table no match

If the packet drop count keeps increasing, analyze the possible issues according to the packet drop reasons.

If the packet drop count does not increase and the number of packets sent to the CPU also does not increase, it means that packets are not successfully sent to the BRAS. In this case, proceed to the next step.

7. Check the device failures.

¡ Make sure the physical connections of the device are correct.

¡ Make sure the network configuration is correct.

8. If the issue persists, collect the following information and contact Technical Support:

¡ Results of each step.

¡ The configuration file, log messages, and alarm messages.

IPoE NDRS user online failures and abnormal offline events

Symptom

An IPoE NDRS user fails to come online or abnormally goes offline.

Common causes

The following the common causes of this type of issue:

· Configuration errors exist. For example:

¡ The access interface is not enabled with IPv6.

¡ The IPoE access mode is incorrect.

¡ No IPv6 prefix is authorized.

¡ The ND prefix pool is incorrect.

· User authentication fails.

· The user is blocked.

· No user packets are received.

Troubleshooting flow

Figure 8 shows the troubleshooting flowchart

Figure 8 Flowchart for troubleshooting IPoE NDRS user online failures and abnormal offline events

Solution

1. Use the display aaa online-fail-record command to identify the online failure reason.

<Sysname> display aaa online-fail-record

Username: user1

Domain: dm1

MAC address: 0000-5e00-01cc

Access type: IPoE

Access UP ID: 1353

Access interface: XGE3/1/1

SVLAN/CVLAN: -/-

IP address: -

IPv6 address: -

Online request time: 2021/08/15 06:09:54

Online failure reason: No prefix available

The Online failure reason field in the command output displays the user online failure reason. You can roughly locate the fault based on the failure reason, which provides guidance for later troubleshooting. Search for the displayed reason in "Appendix A Reasons for user login failures and abnormal logouts" and troubleshoot according to the corresponding solution.

You can resolve the issues caused by some failure reasons (for example, Authentication method error, Local authentication request was rejected, or No prefix available) by checking the configuration. If you cannot see the failure records for some failure reasons, proceed to the next step.

2. Use the display aaa offline-record command to identify the offline reason.

Search for the displayed reason in "Appendix A Reasons for user login failures and abnormal logouts" and troubleshoot according to the corresponding solution.

If you cannot use the display aaa offline-record command to obtain the user offline reasons, proceed with the next step.

3. Check whether the IPoE NDRS user settings are correct.

Troubleshoot the settings according to the manuals for BRASs. For example, see tasks at a glance or configuration examples in the corresponding manuals.

¡ If configuration errors exist, correct the configuration and then try to come online again.

¡ If the configuration is correct but the issue persists, proceed to the next step.

4. Execute the display ppp chasten user command to identify whether the user is blocked by IPoE.

If the user is blocked, redial after the remaining blocking time expires according to the command output. If the user is not blocked, proceed to the next step.

5. Check whether the UCM and IPoE modules receive packets.

Execute the following commands for troubleshooting and collect service trace messages:

¡ Execute the trace access-user command to enable service tracing.

¡ Execute the debugging ip subscriber all command to enable IPoE debugging.

¡ Execute the terminal debugging and terminal monitor commands to enable output of debugging messages to the current terminal and enable log output to the current terminal.

If no packets are received, proceed to the next step.

6. Check whether the BRAS receives user packets.

<Sysname> system-view

[Sysname-probe] probe

[Sysname-probe] display hardware internal rxtx packet statistic slot 3 cpu 0

Net port packet loss count:

code counter

Rx packets statistic:

counter success rate

NET ->RXTX : 3177780 3177780 9 pps

Cpu code input list:(Mgment to L1 queue)

code counter success(whitelist/normal)

5 2057 2057(0/2057)

6 2077 2077(0/2077)

17 98 98(0/98)

18 48 48(0/48)

30 2091197 2091197(0/2091197)

35 573 573(0/573)

43 565 565(0/565)

45 4327 4327(0/4327)

49 79488 79488(0/79488)

50 85 85(0/85)

53 69830 69830(69823/7)

54 46567 46567(46566/1)

57 161707 161707(0/161707)

59 13052 13052(13044/8)

60 26280 26280(13953/12327)

61 30 30(0/30)

153 593518 593518(593513/5)

185 4354 4354(0/4354)

194 81927 81927(0/81927)

Callback function packets statistic:

total(r) success(r) total(c) success(c)

MACL: 0 0 0 0

NATL: 0 0 0 0

BFD: 0 0 0 0

(null): 0 0 0 0

Task input pkt statistics:

Task name total success

Main Task : 1086583 1086583

Icmp Task : 0 0

Cpu code input list:(L2 queue to platform)

code counter success drop rate

5 2057 2057 0 0

6 2077 2077 0 0

17 98 98 0 0

18 48 48 0 0

35 573 573 0 0

43 565 565 0 0

45 4327 4327 0 0

49 79488 79488 0 0

50 85 85 0 0

53 69830 69830 0 0

54 46567 46567 0 0

57 161707 161707 0 0

59 13052 13052 0 0

60 26280 26280 0 0

61 30 30 0 0

153 593518 593518 0 1

185 4354 4354 0 0

194 81927 81927 0 0

Cpu code to protocol:

5 ARP_REQ_LOCAL

6 ARP_REL

17 ARP_REQ

18 ARP_REQ_PROXY

30 DIAG

35 ND_NA

43 ND_NS

45 ND_RA

49 OSPF_HELLO,OSPF_LSU,OSPF_LSACK

50 OSPF_DD,OSPF_LSR

53 LDP_HELLO

54 LDP_NOTIF,LDP_INIT,LDP_KPALV,LDP_ADDR,LDP_LABEL

57 ISIS

59 BGP

60 BGP4P_IPV6

61 DHCP_IPOE,DHCP_SNOOPING,DHCP,DHCPv6_RELAY,DHCPv6_RELS,DHCPv6_SERV

153 IP_VSRP

185 VXLAN_GPE

194 CUSP

Debug packets statistic:

counter counter rate

NET->RXTX->SERVICE: 0 0 0 pps

SERVICE->RXTX->NET: 0 0 0 pps

failed

MbufTrSend: 0

FoundIfindex: 0

SaveCoreSta: 0

MainCoreSta: 0

TxFailedSta: 0

If the received packet counts increase, it means that the device has received ARP, ND, or unknown IP packets and sent them to the related function modules. If the counts do not increase, execute the display hardware internal np pktcnt drop command to identify whether the driver has packet drop count.

<Sysname> system-view

[Sysname-probe] probe

[Sysname-probe] display hardware internal np pktcnt drop slot 3 (the command for viewing the packet count varies by device model)

Current Mcode Type: SIRIUS_RELEASE

The NP 0 is Both NP

Drop packet statistics

32B7 116497 TOPparse total discarded pkts

350F 916677 TOPresolve total discarded pkts

51A 66 PRS Ingress route interface deny L2 forward

56B 384 PRS Ingress Route interface deny L2 forward

63C 403633 RSV Ingress ARP packet FTN or BROADCAST table no ma

tch

63E 372789 RSV Ingress PROTOCOL_MAC and BROADCAST table no mat

641 161878 RSV Ingress PROTOCOL_MAC.THB is set, but BROADCAST

table no match

645 149489 RSV Ingress multicast, MULTICAST.DROP is set

646 144150 RSV Ingress multicast, match MULTICAST default entr

y, but BROADCAST table no match

663 4 RSV Ingress broadcast packets from route port, PROT

OCOL_PORT table no match

If the dropped packet count keeps increasing, analyze the possible issues according to the packet drop reasons.

If the dropped packet count does not increase and the number of packets sent to the CPU also does not increase, it means that packets are not successfully sent to the BRAS. In this case, proceed to the next step.

7. Check the device failures.

¡ Make sure the physical connections of the device are correct.

¡ Make sure the network configuration is correct.

8. If the issue persists, collect the following information and contact Technical Support:

¡ Results of each step.

¡ The configuration file, log messages, and alarm messages.

IPoE static user online failure or abnormal offline event

Symptom

An IPoE static user fails to come online or abnormally goes offline.

Common causes

The following are the common causes of this type of issue:

· Incorrect user settings.

· The IP address of the user is assigned dynamically to another user.

· Authentication failure.

· The user is blocked.

· The user packets fail to be sent to the BRAS device.

Troubleshooting flow

Figure 9 shows the troubleshooting flowchart.

Figure 9 Flowchart for troubleshooting IPoE static user online failure or abnormal offline event

Solution

1. View the reason causing online failure of the IPoE static user.

Execute the display aaa online-fail-record command to display the user online failure reason.

<Sysname> display aaa online-fail-record

Username:

Domain:

MAC address: 0000-5e00-01cc

Access type: IPoE

Access UP ID: 1353

Access interface: XGE3/1/1

SVLAN/CVLAN: -/-

IP address: 2.2.2.9

IPv6 address: -

Online request time: 2021/08/15 06:09:54

Online failure reason: static user not config

The Online failure reason field in the command output displays the user online failure reason. You can roughly locate the fault based on the failure reason, which provides guidance for later troubleshooting. Search for the displayed reason in "Appendix A Reasons for user login failures and abnormal logouts" and troubleshoot according to the corresponding solution.

You can resolve the issues caused by some failure reasons such as Authentication method error, Local authentication request was rejected, and Static user not config by correcting the configuration. If you cannot see the reason for the failure, proceed with the next step.

2. View the IPoE user offline reason.

If you cannot obtain the online failure reason for the user in step 1, the user might come online successfully and then go offline. In this case, use the display aaa offline-record command to display user offline records.

If the user first comes online successfully and then goes offline, the Offline reason field in the command output displays the offline reason. You can roughly locate the fault based on the failure reason, which provides guidance for later troubleshooting.

Search for the displayed reason in "Appendix A Reasons for user login failures and abnormal logouts" and troubleshoot according to the corresponding solution.

If you cannot use the display aaa offline-record command to obtain the user offline reason, proceed with the next step.

3. Verify that the IPoE static user settings are correct.

Check the IPoE static user settings by referring to the manuals for the BRAS product. For example, view tasks at a glance and configuration examples in the configuration guide for the related module.

¡ If there are incorrect settings, correct the settings and then try to come online again.

¡ If the settings are correct but the issue persists, proceed with the next step.

4. Identify whether the user has been blocked.

Execute the display ip subscriber chasten user quiet command to identify whether the user has been blocked.

¡ If the user has been blocked, redial after the remaining blocking time expires.

¡ If the user is not blocked, identify whether protocol packet loss occurs during packet transmission to the related modules on the BRAS device.

5. Verify that related modules have received packets from the user.

¡ If the static user uses unclassified-IP packet initiation, execute the debugging ip subscriber packet command to enable IPoE packet receipt and transmit debugging and troubleshoot based on debugging information.

¡ If the static user uses ARP packet initiation, execute the debugging arp packet interface ten-gigabitethernet xxx command to enable ARP packet receipt and transmit debugging and troubleshoot based on debugging information.

¡ If the static user uses ND packet initiation, execute the debugging ipv6 nd packet interface ten-gigabitethernet xxx command to enable ND packet receipt and transmit debugging and troubleshoot based on debugging information.

¡ Execute the following commands to enable service tracing messages, and collect service tracing messages and troubleshoot based on the messages.

- Execute the trace access-user command to enable service tracing.

- Execute the debugging ip subscriber all command to enable IPoE debugging.

- Execute the terminal debugging and terminal monitor commands to enable output of debugging messages to the current terminal and enable log output to the current terminal.

If the related modules have not received packets from the user, proceed with the next step.

6. Verify that the user packets have been sent to the BRAS device.

Execute the display hardware internal rxtx packet statistic command in probe view to view statistics about packets transmitted and received on the device driver

<Sysname> system-view

[Sysname-probe] probe

[Sysname-probe] display hardware internal rxtx packet statistic slot 3 cpu 0

Net port packet loss count:

code counter

Rx packets statistic:

counter success rate

NET ->RXTX : 3177780 3177780 9 pps

Cpu code input list:(Mgment to L1 queue)

code counter success(whitelist/normal)

5 2057 2057(0/2057)

6 2077 2077(0/2077)

17 98 98(0/98)

18 48 48(0/48)

30 2091197 2091197(0/2091197)

35 573 573(0/573)

43 565 565(0/565)

45 4327 4327(0/4327)

49 79488 79488(0/79488)

50 85 85(0/85)

53 69830 69830(69823/7)

54 46567 46567(46566/1)

57 161707 161707(0/161707)

59 13052 13052(13044/8)

60 26280 26280(13953/12327)

61 30 30(0/30)

153 593518 593518(593513/5)

185 4354 4354(0/4354)

194 81927 81927(0/81927)

Callback function packets statistic:

total(r) success(r) total(c) success(c)

MACL: 0 0 0 0

NATL: 0 0 0 0

BFD: 0 0 0 0

(null): 0 0 0 0

Task input pkt statistics:

Task name total success

Main Task : 1086583 1086583

Icmp Task : 0 0

Cpu code input list:(L2 queue to platform)

code counter success drop rate

5 2057 2057 0 0

6 2077 2077 0 0

17 98 98 0 0

18 48 48 0 0

35 573 573 0 0

43 565 565 0 0

45 4327 4327 0 0

49 79488 79488 0 0

50 85 85 0 0

53 69830 69830 0 0

54 46567 46567 0 0

57 161707 161707 0 0

59 13052 13052 0 0

60 26280 26280 0 0

61 30 30 0 0

153 593518 593518 0 1

185 4354 4354 0 0

194 81927 81927 0 0

Cpu code to protocol:

5 ARP_REQ_LOCAL

6 ARP_REL

17 ARP_REQ

18 ARP_REQ_PROXY

30 DIAG

35 ND_NA

43 ND_NS

45 ND_RA

49 OSPF_HELLO,OSPF_LSU,OSPF_LSACK

50 OSPF_DD,OSPF_LSR

53 LDP_HELLO

54 LDP_NOTIF,LDP_INIT,LDP_KPALV,LDP_ADDR,LDP_LABEL

57 ISIS

59 BGP

60 BGP4P_IPV6

61 DHCP_IPOE,DHCP_SNOOPING,DHCP,DHCPv6_RELAY,DHCPv6_RELS,DHCPv6_SERV

153 IP_VSRP

185 VXLAN_GPE

194 CUSP

Debug packets statistic:

counter counter rate

NET->RXTX->SERVICE: 0 0 0 pps

SERVICE->RXTX->NET: 0 0 0 pps

failed

MbufTrSend: 0

FoundIfindex: 0

SaveCoreSta: 0

MainCoreSta: 0

TxFailedSta: 0

If the received ARP, ND, or unclassified IP packet count has increased, the device has received the packets and sent them to the platform. You can use debugging for the forwarding function to check the layer on which packets are dropped step by step. If the count does not increase, execute the display hardware internal np pktcnt drop command to identify whether the driver has dropped packets.

<Sysname> system-view

[Sysname-probe] probe

[Sysname-probe] display hardware internal np pktcnt drop slot 3 (the command for viewing the packet count varies by device model)

Current Mcode Type: SIRIUS_RELEASE

The NP 0 is Both NP

Drop packet statistics

32B7 116497 TOPparse total discarded pkts

350F 916677 TOPresolve total discarded pkts

51A 66 PRS Ingress route interface deny L2 forward

56B 384 PRS Ingress Route interface deny L2 forward

63C 403633 RSV Ingress ARP packet FTN or BROADCAST table no ma

tch

63E 372789 RSV Ingress PROTOCOL_MAC and BROADCAST table no mat

641 161878 RSV Ingress PROTOCOL_MAC.THB is set, but BROADCAST

table no match

645 149489 RSV Ingress multicast, MULTICAST.DROP is set

646 144150 RSV Ingress multicast, match MULTICAST default entr

y, but BROADCAST table no match

663 4 RSV Ingress broadcast packets from route port, PROT

OCOL_PORT table no match

¡ If the dropped packet count keeps increasing, analyze the possible issues according to the packet drop reasons.

¡ If the dropped packet count does not increase and the number of packets sent to the CPU also does not increase, packets are not successfully sent to the BRAS. In this case, proceed with the next step.

7. Check whether faults are present on the device.

¡ Make sure the physical connections of the device are correct.

¡ Make sure the network settings of the device are correct.

8. If the issue persists, collect the following information and contact Technical Support:

¡ Results of each step.

¡ The configuration file, log messages, and alarm messages.

IPoE Web user online failure

Web authentication page not showing up

Symptom

When an IPoE user accesses the Web authentication page or access another page than the Web authentication page, the Web authentication page does not show up.

Common causes

The following are the common causes of this type of issue:

· The Web authentication page URL is configured incorrectly in preauthentication view.

· The QoS policy is configured incorrectly in the preauthentication phase.

· Disconnectivity between the host, server, and device.

· HTTP proxy has been enabled in the browser.

· The URL entered by the user uses a non-standard TCP port number.

· An issue has occurred on the intermediate network or DNS server.

· HTTPS redirection on the device is abnormal.

· The HTTPS website accessed by the user has enabled with HTTP Strict Transport Security (HSTS).

· The portal server cannot recognize URL escape codes.

· Portal server configuration error.

Troubleshooting flow

Figure 10 shows the troubleshooting flowchart.

Figure 10 Flowchart for troubleshooting Web authentication page not showing up

Solution

1. Verify that the user has passed preauthentication.

If the user fails to pass preauthentication, resolve the issues to ensure that it can pass preauthentication.

2. Verify that Web authentication settings are correct.

¡ Verify that the IP address of the portal authentication server is configured correctly on the BRAS device.

¡ Verify that the Web authentication page URL is configured correctly on the BRAS device.

¡ Verify that the QoS policy settings for preauthentication are configured correctly on the BRAS device:

- Inbound direction: Allow packets with the portal server as the destination address to pass through.

- Outbound direction: Allow packets with the portal server as the source address to pass through.

¡ Verify that the device has been bound to an IP address group on the portal server.

¡ Verify that the endpoint IP address is within the range of the IP address group configured on the Portal server.

3. Verify that the route settings on the endpoint and the portal server are correct.

a. Disable firewall on the endpoint and ping the portal server from the endpoint. If the ping operation fails, first identify whether the route settings on the endpoint and portal server are correct, and then check the following items:

- Whether the route from the portal server to the endpoint is configured correctly.

- Whether multiple network cards exist on the endpoint and portal server.

If multiple network cards exist, not all traffic between the endpoint and the server will go through the network with portal authentication. Check specific route information and determine from which network cards the Web access traffic goes out. For example, if you are using a Windows endpoint, execute the route print command in the CLI to view specific routing information.

b. Perform ping operations by hop. First ping the gateway from the endpoint (authentication must be disabled first), and then ping the server from the gateway.

4. Identify whether HTTP proxy is enabled in the endpoint browser.

Enabling HTTP proxy in the browser will prevent users from accessing the portal authentication page. You must disable HTTP proxy in the browser. For example, to disable HTTP proxy in a Windows IE browser, click Tools, select Internet Options > Connections > LAN Settings > Proxy Server, and then turn off HTTP proxy.

5. Identify whether the entered URL uses a non-standard TCP port.

Non-standard TCP ports are non-80 or non-443 ports. If the URL entered by the user contains a non-standard TCP port, for example, http://10.1.1.1:18008, the portal authentication page will not pop up. For an HTTP URL, use port number 80. For an HTTPS URL, use port number 443.

6. Identify whether there are any issues with the intermediate network or DNS server.

¡ Identify whether the DNS server IP address is allowed on the device.

¡ Identify the intermediate network connectivity and determine whether a fault has occurred on the DNS server. On the gateway, collect traffic statistics on the downlink interface connecting the endpoint and uplink interface connecting the DNS server or mirror the endpoint messages that access the DNS server. Determine whether the gateway has sent out DNS requests but not received a response message.

7. Identify whether HTTPS redirection is enabled.

a. Identify whether the user is accessing the HTTPS website. If yes, execute the display current-configuration command to identify whether the http-redirect https-port command is executed on the current device.

- If the http-redirect https-port command is executed, execute the display tcp command to identify whether the listening port specified in the http-redirect https-port command is properly opened. If the specified listening port is not opened, execute the http-redirect https-port command again to ensure that the specified listening port is properly opened.

- If the http-redirect https-port command is not executed, the current device uses the default port 6654 of the http-redirect https-port command. Execute the display tcp command to identify whether the default listening port 6654 is properly opened. If the specified listening port is not opened, execute the http-redirect https-port 6654 command again to ensure that the default listening port is properly opened.

b. Identify whether an SSL server policy for HTTPS redirection exists. If no such policy exists, configure it.

8. Identify whether the HTTPS website has been enabled with HSTS.

If the HTTPS website has been enabled with HSTS, a browser must use HTTPS to access the HTTPS website, and the certificate must be valid. To redirect the HTTPS request from a browser, the device will use a self-signed certificate (the device does not have a certificate from the target website, and can only use a self-signed certificate) in the disguise of the target website to establish an SSL connection with the browser. Once the browser detects that the certificate is not trusted, HTTPS redirection fails and the portal authentication page will not pop up. This situation depends on the HSTS mandatory requirements on the website and cannot be resolved. In this case, try to access another website.

9. If the issue persists, collect the following information and contact Technical Support:

¡ Results of each step.

¡ The configuration file, log messages, and alarm messages.

¡ Snapshots of portal related configuration on the portal server.

¡ Packet capture files for packet transmission between the device and server.

¡ Snapshots of the client browser issues.

¡ Debugging information collected by executing the debugging portal and debugging portal commands.

Access failure to the Web authentication page

Symptom

A user fails Web authentication or an authentication anomaly occurs.

Common causes

The following are the common causes of this type of issue:

· The shared key configured in portal authentication server view on the BRAS device is inconsistent with that on the portal authentication server.

· The portal authentication server address configured in portal authentication server view on the BRAS device does not exist.

· The portal messages received on the BRAS device are invalid.

· The IPS domain used by the Web user is incorrect.

· The shared key configured in RADIUS view is inconsistent with that on the RADIUS server.

· The RADIUS server rejects the authentication request.

· The RADIUS server does not respond.

Troubleshooting flow

Figure 11 shows the troubleshooting flowchart.

Figure 11 Flowchart for troubleshooting access failure to the Web authentication page

Solution

1. Identify whether the shared key configured in portal authentication server view on the BRAS device is inconsistent with that on the portal authentication server.

If a request timeout message is displayed on the Web login page after you enter the username and password on the page for coming online, the shared key configured in portal authentication server view on the BRAS device might be inconsistent with that on the portal authentication server.

Execute the debugging portal error command on the BRAS device and enable portal error debugging. If following information is generated on the device, the shared key configured on the BRAS device is inconsistent with that on the portal server.

*Jul 28 17:51:20:774 2021 Sysname PORTAL/7/ERROR: -MDC=1; Packet validity check failed due to invalid key.

If the shared key configured on the BRAS device is inconsistent with that on the portal server, change the shared key configured in portal server view on the BRAS device or the shared key configured on the portal authentication server to ensure that they are consistent.

2. Identify whether the portal authentication server IP address configured in portal authentication server view on the BRAS device exists.

When the portal server receives an authentication packet from the BRAS device, it will verify whether the source IP of the message is an allowed IP. If the IP is not allowed, the packet is considered invalid and will be discarded directly.

If a request timeout message is displayed on the Web login page after you enter the username and password on the page for coming online, the portal authentication server IP address configured in portal authentication server view on the BRAS device exist might not exist.

Execute the debugging portal error command on the BRAS device and enable portal error debugging. If following information is generated on the device, the portal authentication server IP address configured on the device is incorrect.

*Jul 28 19:15:10:665 2021 Sysname PORTAL/7/ERROR: -MDC=1;Packet source unknown. Server IP:192.168.161.188, VRF Index:0.

If the portal authentication server IP address configured on the device is incorrect, execute the ip command in portal server view to modify the IP address of the portal server.

3. Identify whether the ISP domain is configured correctly on the device.

For authentication to be performed on users, make sure the ISP domain is configured correctly on the device.

If a message that the device rejects the request is generated on the Web login page after you enter the username and password on the page for coming online, the ISP domain might be configured incorrectly.

Execute the debugging portal error command on the BRAS device and enable portal error debugging. If following information is generated on the device, the ISP domain on the device is configured incorrectly.

*Jul 28 19:49:12:725 2021 Sysname PORTAL/7/ERROR: -MDC=1; User-SM [21.0.0.21]: AAA processed authentication request and returned error.

If the ISP domain is configured incorrectly, execute the related command to change the ISP domain used by the Web user to be correct.

4. Identify whether the shared key configured in RADIUS view on the device is consistent with that configured on the RADIUS server.

If a request timeout message is displayed on the Web login page after you enter the username and password on the page for coming online, the shared key configured in RADIUS view on the device might be inconsistent with that configured on the RADIUS server..

Execute the debugging radius error command on the BRAS device and enable RADIUS error debugging. If following information is generated on the device, the shared key configured in RADIUS view on the device is inconsistent with that configured on the RADIUS server.

*Jul 28 19:49:12:725 2021 Sysname RADIUS/7/ERROR: -MDC=1; The response packet has an invalid Response Authenticator value.

When the device sends an authentication request to the RADIUS server, the server will first verify the request message using the shared key. If the verification fails, the server will notify the device that the verification has failed. If the shared key is configured incorrectly, change the key in RADIUS view on the device or the key on the RADIUS server to ensure that they are consistent.

5. Identify whether the portal packets are valid.

When the device receives a portal protocol packet from the portal server, it verifies the validity of the packet. If the packet length or the packet verification segment is incorrect, the packet will be considered invalid and discarded.

Execute the display portal packet statistics command to check whether the number of invalid packets is increasing. If the number of invalid packets is increasing, execute the debugging portal error command to enable portal error debugging for troubleshooting.

If the portal protocol packets are invalid, identify the reason causing message invalidity with the assistance of technical support personnel, resolve the issues, and make sure the portal packets are valid.

6. Identify whether the device fails to obtain user physical information.

During the user's online process, the portal module will obtain the user's physical information and determine interface and other information based on physical information. If the device fails to obtain the user's physical information, the user will fail to go online.

Execute the debugging portal event command and enable portal event debugging. If following information is generated on the device, the device fails to obtain user's physical information.

*Jul 28 19:49:12:725 2021 Sysname PORTAL/7/ERROR: -MDC=1; User-SM [21.0.0.21]: Failed to find physical info for ack_info.

If the device fails to obtain physical information of the user, identify whether an entry for the authentication user exists on the device. If no such entry exists, locate the reason.

7. Identify whether the RADIUS server rejects the authentication request.

There are various reasons why a RADIUS server rejects an authentication request. The most common ones are incorrect username or password and mismatch of the RADIUS server authorization policy. To resolve the issue, first view the authentication logs on the server side or enable RADIUS error debugging on the device to identify the root cause. Then, adjust the server, endpoint, or device configuration according to the root cause.

8. Identify whether the RADIUS server responds.

You can use the following methods to quickly identify whether the RADIUS server responds.

¡ Execute the display radius scheme command on the BRAS device to view the server status. If the status is Blocked, the server is not available.

¡ Identify whether the following message has been generated on the device.

RADIUS/4/RADIUS_AUTH_SERVER_DOWN: -MDC=1; RADIUS authentication server was

blocked: server IP=192.168.161.188, port=1812, VPN instance=public.

¡ Execute the debugging radius event command and enable event debugging for the RADIUS module. If following information is generated on the device, the RADIUS server does not respond.

*Jul 28 19:49:12:725 2021 Sysname RADIUS/7/evnet: -MDC=1; Reached the maximum retries.

If the RADIUS server does not respond, perform the following tasks:

a. Identify whether the device IP address has been added to the server.

- If not added, add the correct device IP address to the server.

- If added, determine whether the IP address of the device added to the server is consistent with the source IP address of the authentication request. The device uses the IP address of the default outgoing interface as the source IP address of the RADIUS authentication request. You can change the source IP address by using the source-ip command as needed. For more information about the source-ip command, see AAA command reference in BRAS Services Command References.

b. Identify whether the link between the device and server is normal, for example, whether the firewall between the two does permit the RADIUS packets (default authentication port: 1812). If a large number of users cannot be authenticated and a RADIUS server down log is generated on the device, the server or intermediate network might be abnormal, which must be identified one by one.

9. If the issue persists, collect the following information and contact Technical Support:

¡ Results of each step.

¡ The configuration file, log messages, and alarm messages.

¡ Snapshots of portal related configuration on the portal server.

¡ Packet capture files for packet transmission between the device and AAA server

¡ Snapshots of the client browser issues.

¡ Debugging information collected by executing the debugging portal command.

Appendix A Reasons for user login failures and abnormal logouts

Identifying the reasons

Identifying login failure reasons

Use the display aaa online-fail-record command to view the login failure reason.

<Sysname> display aaa online-fail-record username 001094500020

Total count: 116

Username: 001094500020

Domain: dm1

MAC address: 0010-9450-0020

Access type: IPoE

Access UP ID: 1353

Access interface: XGE3/1/1

SVLAN/CVLAN: -/-

IP address: -

IPv6 address: -

Online request time: 2021/08/15 07:42:15

Online failure reason: DHCP with server no response

In this example, the online failure reason is DHCP with server no response. To view the recommended troubleshooting methods for the failure, see "Reasons for user login failures and abnormal logouts."

If the failure reason cannot be obtained in the method described above, it indicates that the failure might be caused because AAA authentication has not started or the link between the user and the device is faulty. In this case, use the trace access-user command to identify the stage at which an error occurred and then troubleshoot the link based on the actual networking conditions. For more information about the trace access-user command, see BRAS Services Command Reference.

Identifying abnormal logout reasons

Use the display aaa abnormal-offline-record and display aaa offline-record commands to view the abnormal logout reason.

<Sysname> display aaa offline-record username 001094500021

Total count: 4

Username: 001094500021

Domain: dm1

MAC address: 0010-9450-0021

Access type: IPoE

Access UP ID: 1354

Access interface: XGE3/1/1

SVLAN/CVLAN: -/-

IP address: 9.0.3.1

IPv6 address: -

Online request time: 2021/08/15 08:05:17

Offline time: 2021/08/15 08:09:08

Offline reason: DHCP release

In this example, the online failure reason is DHCP release. To view the recommended troubleshooting methods for the failure, see "Reasons for user login failures and abnormal logouts."

If the failure reason cannot be obtained in the method described above, it indicates that the failure might be caused because the link between the user and the device is faulty. In this case, troubleshoot the link based on the actual networking conditions.

1. Verify that the access device IP added on the authentication server is the same as the source IP address in the authentication request packets sent by the device.

2. Verify that the device can reach the authentication server.

AAA with authorization data error

Message

AAA with authorization data error

Reasons

The device fails to parse the authorization information issued by the server.

Recommended actions

1. Enable debugging for RADIUS packets and view the authorization attributes.

2. Verify that the authorization attributes issued by the server are correct.

AAA with flow limit

Message

AAA with flow limit

Reasons

The traffic quota of the online user is exhausted.

Recommended actions

No action is required.

AAA with memory alloc fail

Message

AAA with memory alloc fail

Message

AAA with realtime accounting fail

Reasons

A user goes offline because real-time accounting fails.

Recommended actions

1. Identify whether the shared key on the device matches that on the accounting server. If they do not match, set the shared key matching that on the server in the accounting scheme.

2. Identify whether the accounting update-fail [ max-times max-times ] offline command is executed in the ISP domain. By default, a user stays online when real-time accounting fails. For a user not to go offline when real-time accounting fails, execute the accounting update-fail online command or execute the undo accounting update-fail command to restore the default.

3. If the issue persists, contact Technical Support.

AAA with start accounting fail

Message

AAA with start accounting fail

Reasons

Failed to start accounting for a user coming online.

Recommended actions

1. Check the accounting configuration in the ISP domain, and verify that the accounting scheme is correct.

2. Identify whether the accounting start-fail offline command is executed in the ISP domain. By default, a user stays online if accounting fails to start for the user. For a user not to go offline when accounting fails to start, execute the accounting start-fail online command or execute the undo accounting start-fail command to restore the default.

AAA with timer create fail

Message

AAA with timer create fail

Reasons

Failed to create the AAA timer on the device.

Recommended actions

1. Use the display memory command to view the memory usage of the device, and identify whether the memory of the device is sufficient.

2. Use the display memory-threshold command to identify whether the memory threshold alarms exist. According to the value for the Current free-memory state: field, check the memory alarm state.

3. Clear the memory as needed, for example, reduce the number of online users or close some unneeded services.

AAA with user information err

Message

AAA with user information err

Reasons

When a user performs LDAP authentication, the user does not provide the required username.

Recommended actions

Modify the username of the user for coming online, and log in again.

access-block

Message

access-block

Reasons

On a CUPS network, the access UP of a user prevents new users from coming online.

Recommended actions

Execute the undo access-block command on the access UP of the user to configure the UP to allow new users to come online. Example:

<Sysname> system-view

[Sysname] up-manage id 1024

[Sysname-up-manage-1024] undo access-block

Add nat user data fail(IP Alloc Fail)

Message

Add nat user data fail(IP Alloc Fail)

Reasons

In the NAT configuration matching traffic of a user, the NAT address group does not have enough public network addresses.

Recommended actions

In the NAT address group, the public network address resources are obtained in one of the following methods:

· Execute the address command in NAT address group view to add address resources. When address resources are insufficient, execute the address command to add address resources. Example:

<Sysname> system-view

[Sysname] nat address-group 1

[Sysname-address-group-1] address 202.1.1.1 202.1.1.2

· Bind a NAT address group to the global NAT address pool. Then, the NAT address group obtains address resources from the global NAT address pool.

¡ For a static global NAT address pool, manually add address resources when the address resources are insufficient. Example:

<Sysname> system-view

[Sysname] nat ip-pool pool1

[Sysname-nat-ip-pool-pool1] section 0 200.1.1.1 mask 24

Add no backlist no Sub IfMaster

Message

Add no backlist no Sub IfMaster

Reasons

If master/backup switchover occurs on a UP backup network, the current configured backup interface is the actual running master interface, and the configured master interface is the actual running backup interface. In this case, users come online through subinterfaces on the configured backup interface (running master interface). However, the device fails to find subinterfaces on the configured master interface (running backup interface). As a result, the users cannot come online.

Recommended actions

Identify whether the subinterface on the configured master interface is configured to terminate the VLAN tag carried in packets. For example, the subinterface on the configured master interface is configured to terminate packets carrying VLAN tag 3 rather than VLAN tag 2, but the user packets carry VLAN tag 2. In this case, you can configure the subinterface on the configured master interface to terminate packets carrying VLAN tag 2. Then, trigger the users to come online again.

An ODAP IP address pool group does not have available subnets for allocation.

Recommended actions

· In the IP address pool group, execute the network secondary command to create new secondary subnets. Then, use the new secondary subnets to allocate available subnets.

· Crete a new ODAP IP address pool, and configure subnets available for allocation. Then, use the pool command to add the address pool to the IP address group.

All subnets in the DHCP address pool have been allocated

Message

All subnets in the DHCP address pool have been allocated

Reasons

An ODAP IP address pool does not have available subnets for allocation.

Recommended actions

· In the IP address pool, execute the network secondary command to create new secondary subnets. Then, use the new secondary subnets to allocate available subnets.

· The user can come online through another interface. The DHCP server will authorize a new address pool to the user. If the DHCP server does not have a new address pool that can be authorized, you must re-create the address pool.

All subnets in the DHCPv6 address pool group have been allocated

Message

All subnets in the DHCPv6 address pool group have been allocated

Reasons

An ODAP IPv6 address pool group does not have available subnets for allocation.

Recommended actions

Crete a new ODAP IPv6 address pool, and configure subnets available for allocation. Then, use the pool command to add the address pool to the IPv6 address group.

All subnets in the DHCPv6 address pool have been allocated

Message

All subnets in the DHCPv6 address pool have been allocated

Reasons

An ODAP IPv6 address pool does not have available subnets for allocation.

Recommended actions

ARP with detect fail

Message

ARP with detect fail

Reasons

· The intermediate transmission devices drop or modify the ARP detection packets.

· Link failures occur.

· The detection packets are dropped by the device.

· The device drops packet because of access method, interface state, and user information errors.

Recommended actions

View the online and offline time difference of the user. View the detection settings. Execute the trace access-user command to create a service tracing object and view the packet sending/receiving conditions. Identify the phase at which a packet was lost, and troubleshoot accordingly.

Authenticate fail

Message

Authenticate fail

Reasons

A local management user fails to pass authentication and come online.

Recommended actions

· Verify that the username and password entered are correct.

· Check the authentication configuration in the ISP domain, and verify that the authentication scheme configuration is correct.

Authentication method error

Message

Authentication method error

Reasons

· The authentication method configured is incorrect. For example, a user comes online as a static leased user but the configured authentication method is Web.

· LDAP supports only the PAP authentication mode. The client uses an authentication method other than PAP.

Recommended actions

Modify the configuration and trigger the user to come online again.

Authorize fail

Message

Authorize fail

Message

DHCP free lease with command

Reasons

Execute the reset dhcp server ip-in-use, reset ipv6 dhcp server ip-in-use, and reset ipv6 dhcp server pd-in-use commands to delete the user lease information.

Recommended actions

Recommended actions

· If the user does not actively renew the lease, it is normal that the user goes offline.

· If the user has requested for lease renewal, collect the debugging information to locate issues, and troubleshoot the errors. If the issue persists, contact Technical Support.

DHCP memory error

Message

DHCP memory error

Reasons

Failed to apply for the memory.

Recommended actions

Execute the display memory command to view the memory usage of device. If the memory usage reaches the threshold, wait until the memory usage drops below the threshold and then trigger users to come online again. If the memory usage does not reach the threshold, contact Technical Support.

DHCP packet info did not match

Message

DHCP packet info did not match

Reasons

· When a DHCP relay agent receives a reply from the DHCP server, the DHCP relay agent detects a conflict with the recorded user address entry. In this case, the DHCP relay agent drops the reply and the user fails to come online.

· When an ND RS user comes online, the device finds that the client information carried by the ND RS user is different from the authorization information. As a result, the user fails to come online.

Recommended actions

Contact Technical Support.

DHCP release

Message

DHCP release

Reasons

A DHCP user actively sends a RELEASE packet to request going offline.

Recommended actions

No action is required.

DHCP retrieved unexpected IP address

Message

DHCP retrieved unexpected IP address

Message

Domain denied

Reasons

The access interface of the user is configured to prevent users in the ISP domain from coming online.

Recommended actions

Identify whether the aaa deny-domain isp-name command is executed on the interface to prevent users in the specified ISP domain from coming online. Example: Configure the interface to prevent users in ISP domain test from coming online.

<Sysname> system-view

[Sysname] interface ten-gigabitethernet 3/1/1

[Sysname-Ten-GigabitEthernet3/1/1] display this

interface Ten-GigabitEthernet3/1/1

port link-mode route

aaa deny-domain test

To cancel the limit, execute the undo aaa deny-domain isp-name command on the interface.

domain is block

Message

domain is block

Reasons

The ISP domain of the user is blocked, and users in the ISP domain cannot request network services.

Recommended actions

Identify whether the state block offline command is executed in the ISP domain to block the ISP domain and forcibly log out users.

<Sysname> system-view

[Sysname] domain name test

[Sysname-isp-test] display this

The user's private network address is invalid.

Recommended actions

1. Delete the NAT-BRAS collaboration configuration in the ISP domain. Example:

<Sysname> system-view

[Sysname] domain name cgn

[Sysname-isp-cgn] undo user-address-type private-ipv4

The following types of user addresses support collaboration with BRAS: private IPv4 addresses (private-ipv4), private dual-stack addresses (private-ds), and lite dual-stack addresses (ds-lite). If related configuration exists, delete the configuration in the ISP domain.

2. Cancel the binding between the load-sharing user group and NAT instance. Example:

<Sysname> system-view

When a user is performing LDAP authentication, the device cannot send the requests for searching for user DNs.

Recommended actions

Enter the LDAP server view, and execute the search-base-dn command to specify the base DN for user search. Example: Specify the base DN for user search:

<Sysname> system-view

[Sysname] ldap server ldap1

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

Failed to come online by using CGN because service-instance-group is invalid

Message

Failed to come online by using CGN because service-instance-group is invalid

Reasons

· The service instance group bound to the NAT instance does not exist.

· The service instance group bound to the NAT instance is not associated with an effective failover group.

Recommended actions

· If the service instance group bound to the NAT instance does not exist, execute the service-instance-group command to create a service instance group, and execute the failover-group command to associate the service instance group with a failover group. Example:

<Sysname> system-view

[Sysname] service-instance-group sgrp

[Sysname-service-instance-group-sgrp] failover-group failgrp

· Use the display failover command to display failover group information. If the value for the Active Status field is Initial, no nodes in the failover group can process services. If the value for the Active Status field is Primary or Secondary, the failover group can normally process services. Associate the service instance group with a failover group that can normally process services.

Failed to compose tacacs request packet

Message

Failed to compose tacacs request packet

[Sysname-isp-test] authentication ppp radius-scheme rd1

[Sysname-isp-test] authorization ppp radius-scheme rd1

[Sysname-isp-test] accounting ppp radius-scheme rd1

Failed to find the BRAS user

Message

Failed to find the BRAS user

Possible reasons

The corresponding BRAS user information gets lost unexpectedly, and the system cannot find the BRAS user during the association of a PPPoEA user.

Recommended actions

Contact Technical Support.

Failed to get NAT instance

Message

Failed to get NAT instance

Possible reasons

The NAT instance used for user login authorization does not exist.

Recommended actions

· Use the user-group bind nat-instance command to edit the NAT instance associated with the load-sharing user group in the ISP domain. Make sure the load-sharing user group is associated with the same NAT instance as that applied to the device. For example:

<Sysname> system-view

[Sysname] domain name cgn

[Sysname-isp-cgn] user-group name ugrp bind nat-instance inst

Failed to get user’s DN from the ldap search result

Message

Failed to get user’s DN from the ldap search result

Possible reasons

The device has failed to obtain the user’s DN from the LDAP server.

Recommended actions

Message

Flow-triggered port block assignment does not support CGN

Possible reasons

In a NAT+BRAS scenario, when a user comes online, NAT assigns a public IP address and port block to the user. The port block assignment conflicts with the flow-triggered port block assignment configured through the nat port-block flow-trigger enable command.

Recommended actions

Identify whether the nat port-block flow-trigger enable command is executed in system view or NAT instance view. If yes, use the undo nat port-block flow-trigger enable command to disable flow-triggered port block assignment. For example:

<Sysname> system-view

[Sysname] nat instance cgn1 id 1

[Sysname-nat-instance-cgn1] undo nat port-block flow-trigger enable

Force user offline by CUSP aging

Message

Force user offline by CUSP aging

Possible reasons

The CUSP channel is terminated, and the channel fails to be re-established before the CUSP channel aging time expires, which causes users to go offline. The aging time is configured by using the disconnection entry-aging command in CUSP controller view.

Recommended actions

Use the undo disconnection entry-aging command in CUSP controller view to delete the aging time setting.

Going online failed because matching CGN doesn't support port block

Message

Going online failed because matching CGN doesn't support port block

Possible reasons

In a NAT+BRAS scenario, if the port block parameters are not specified for an NAT configuration, the NAT configuration cannot assign a port block to a user that comes online.

Recommended actions

In address group view of the NAT configuration that applies to the user, use the port-block command to configure the port block parameters. For example:

<Sysname> system-view

[Sysname] nat address-group 1

[Sysname-address-group-1] port-block block-size 256 extended-block-number 1

Hardware not support IPV6 PD prefix with mask longer than 120

Message

Hardware not support IPV6 PD prefix with mask longer than 120

Possible reasons

The hardware device does not support a user with an IPv6 PD prefix longer than 120 bits.

Recommended actions

Verify the IPV6 PD prefix pool settings and make sure the IPv6 PD prefix are shorter than or equal to 120 bits.

ICMP with detect fail

Message

ICMP with detect fail

Possible reasons

· With the firewall configured, the client does not respond to ICMP probe packets.

· The intermediate transmission devices drop or edit the probe packets.

· Failures occur on the link.

· The device drops the probe packets.

· The device drops the packets due to incorrect access methods, incorrect interface status, or incorrect user information.

Recommended actions

Disable the firewall on the client, such as Windows Firewall. If the issue persists, identify at which stage the packets are dropped by the following methods:

· View the time when the user came online and went offline.

· View the probe settings.

· Use the trace access-user command to create a service tracing object.

· View packet transmitting and receiving status.

After you identify at which stage the packets are dropped, perform corresponding actions to deal with the failure.

ICMPv6 with detect fail

Message

ICMPv6 with detect fail

Possible reasons

· With the firewall configured, the client does not respond to ICMP probe packets.

· The intermediate transmission devices drop or edit the probe packets.

· Failures occur on the link.

· The device drops the probe packets.

· The device drops the packets due to incorrect access methods, incorrect interface status, or incorrect user information.

Recommended actions

Disable the firewall on the client, such as Windows Firewall. If the issue persists, identify at which stage the packets are dropped by the following methods:

· View the time when the user came online and went offline.

· View the probe settings.

The hardware resources are insufficient.

Recommended actions

Recommended actions

Identify whether the interface MAC address has been changed by executing the mac-address command through the following methods:

· Use the display history-command all command to display all commands that are saved in the command history buffer for all CLI sessions.

· Use the display logbuffer command to display log buffer information and buffered logs.

· View the log file. You can use the display logfile summary command to obtain the path of the log file, and then execute the more command or export the log file to the local host.

If the interface MAC address has been changed by executing the mac-address command, no actions are required. If not, contact Technical Support.

Interface shutdown

Message

Interface shutdown

Possible reasons

The interface is shut down, which causes the user to go offline or fail to come online.

Recommended actions

Identify whether the interface has been shut down through the following methods:

· Use the display history-command all command to display all commands that are saved in the command history buffer for all CLI sessions.

· When a new user comes online, if the user and an existing user on the device have the same MAC address and VLAN, but they have difference IP addresses (including IPv4 address, IPv6 address, and PD prefix), the new user fails to come online.

· When a new user comes online, if the IP address (including IPv4 address and IPv6 address) that the user obtains is the same as that of an existing online user, the new user will fail to come online.

Recommended actions

1. Identify whether the online user that causes the conflict is a valid user.

¡ If the user is a valid user, no action is required.

¡ If the user is an invalid user, execute the cut access-user command to force the invalid user offline, then let the valid user try to come online again.

Possible reasons

· Errors occur when parsing the SCCCN message.

· The local device cannot recognize the AVP attribute that the SCCCN message carries, which caused the local device fails negotiation.

Recommended actions

Verify settings on the peer and contact Technical Support.

L2TP SCCRQ check fail

Message

L2TP SCCRQ check fail

Message

Ldap admin-binding operation failed

Possible reasons

The DN of the administrator configured on the device is not the same as that of the administrator on the LDAP server.

Recommended actions

Enter LDAP server view, use the login-dn command to edit the DN for the administrator to align the DN with that of the administrator on the LDAP server. For example:

The user goes online through local authentication, but the device does not have such a local user.

Recommended actions

Use the display domain command to identify whether the authentication domain is configured with local authentication. By default, the authentication domain uses local authentication. If the user authentication method is specified as local authentication, use the display local-user command to verify the user configuration on the local device. If the user does not exist on the local device, use the local-user command to create the user configuration on the local device, including the password and service type.

Create device management user test, specify the password as 123456TESTplat&!, and specify the service type as SSH.

<Sysname> system-view

[Sysname] local-user test class manage

[Sysname-luser-manage-test] password simple 123456TESTplat&!

[Sysname-luser-manage-test] service-type ssh

Local-user access-limit

Message

Local-user access-limit

Possible reasons

The number of concurrent logins using the local user name reached the maximum.

Recommended actions

Cancel the limit on the number of concurrent logins using the local user name or increase the maximum number of concurrent logins:

· Use the undo access-limit command to cancel the limit on the number of concurrent logins using the local user name.

<Sysname> system-view

[Sysname] local-user test class manage

[Sysname-luser-manage-test] undo access-limit

· Use the undo access-limit command to increase the maximum number of concurrent logins (10, in this example).

nat online failed because of match config failed

Possible reasons

In a NAT and BRAS unification scenario, the user failed to match a nat outbound command configuration.

Recommended actions

1. Use the display nat outbound command to identify the ACL used to match user traffic. For example:

<Sysname> display nat outbound

NAT outbound information:

Totally 1 NAT outbound rules.

Interface: Ten-GigabitEthernet3/1/1

ACL: 2036 Address group: 1 Port-preserved: Y

NO-PAT: N Reversible: N

Config status: Active

2. Use the display acl command to verify that the ACL matched user traffic. If the xx times matched field is absent, the ACL did not match user traffic. For example:

<Sysname> display acl 2036

Basic IPv4 ACL 2036, 1 rule,

ACL's step is 5

rule 0 permit source 10.210.0.0 0.0.0.255

3. Modify the ACL.

nat online failed because of match session-service-location failed

Message

nat online failed because of match session-service-location failed

Possible reasons

No failover group was specified to process session-based services, or the specified failover group failed to match user traffic.

Recommended actions

1. Use the display current-configuration | include session command to verify that a session service-location acl command configuration exists. For example:

<Sysname> display current-configuration | include session

session service-location acl 2000 failover-group aa

2. If no session service-location acl command configuration exists, execute the session service-location acl. For example:

<Sysname> system-view

[Sysname] session service-location acl 2010 failover-group aa

3. Use the display acl command to verify that the ACL matched user traffic. If the xx times matched field is absent, the ACL did not match user traffic. For example:

<Sysname> display acl 2000

Basic IPv4 ACL 2000, 1 rule,

ACL's step is 5

rule 0 permit source 10.210.0.0 0.0.0.255

4. Modify the ACL.

ND detect fail

Message

ND detect fail

Possible reasons

· Intermediate devices drop or modify ND probe packets.

· Link failures existed.

· The device itself dropped ND probe packets because the access mode, interface state, or user information is incorrect.

Recommended actions

View the difference between the login time and logout time, view probe configuration. Execute the trace access-user command to configure a service tracing object. Observe the packet sending and receiving to identify where packets are lost, and troubleshoot the problem based on the packet loss information.

No AAA response during realtime accounting

Message

No AAA response during realtime accounting

Possible reasons

The device failed to receive response packets for real-time accounting packets from the accounting server.

Recommended actions

1. Verify that the IP address of the device was added on the accounting server and that the added IP address is the same as the source IP address of accounting packets.

2. Verify that the device and the accounting server can reach each other.

No AAA response for accounting start

Message

No AAA response for accounting start

Possible reasons

The device failed to receive an Accounting-Response packet from the accounting server.

Recommended actions

Possible reasons

· An invalid IP address is assigned, or an IP address failed to be assigned.

· Unknown packets were received.

· The BRAS device did not receive a configure ack packet for a configure request after the wait timer expired.

Recommended actions

Examine the device configuration, collect PPP protocol packet information, and contact Technical Support.

PPP IPCP terminate

Message

PPP IPCP terminate

Possible reasons

The device received an ipcp terminal request from the client and forcibly logged out the user.

Recommended actions

No action is required.

PPP IPv6CP negotiate fail

Message

PPP IPv6CP negotiate fail

Possible reasons

· Unknown packets were received.

· The BRAS device did not receive a configure ack packet for a configure request after the wait timer expired.

Recommended actions

Recommended actions

1. Verify that the device configuration is correct.

2. If the problem persists, contact Technical Support.

PPP Recover failed

Message

PPP Recover failed

Possible reasons

The PPP session failed to be recovered.

Recommended actions

Contact Technical Support.

PPP recv ip6cp Protocol Reject

Message

PPP recv ip6cp Protocol Reject

Possible reasons

The device received an IPv6CP reject packet, which might indicate option negotiation failures.

Recommended actions

1. Verify that the device configuration is correct.

2. If the problem persists, contact Technical Support.

PPP recv ipcp Protocol Reject

Message

PPP recv ipcp Protocol Reject

Possible reasons

The device received an IPCP reject packet, which might indicate option negotiation failures.

Recommended actions

1. Verify that the device configuration is correct.

2. If the problem persists, contact Technical Support.

PPP up recv ip6cp again

Message

PPP up recv ip6cp again

Possible reasons

· Repeated IPv6CP negotiation packets were received when the IPv6CP is in open state. This might be because the client re-initiated a connection after being disconnected.

· IPv6CP negotiation packets were retransmitted.

Recommended actions

1. Use the display system internal ucm statistics packets command to check whether packet loss occurred.

2. Capture packets and troubleshoot link failures.

3. If the problem persists, contact Technical Support.

PPP up recv ipcp again

Message

PPP up recv ipcp again

Possible reasons

· Repeated IPCP negotiation packets were received when the IPCP is in open state. This might be because the client re-initiated a connection after being disconnected.

PPP wait chap response time out

Message

Radius authentication and authorization do not same

Possible reasons

The RADIUS authentication server and authorization server used during RADIUS authentication are different servers.

Recommended actions

Verify that the authentication and authorization methods use the same RADIUS scheme in an ISP domain.

If the authentication and authorization methods use different RADIUS schemes, configure the same RADIUS scheme in the ISP domain.

<Sysname> system-view

For an unclassified-IP user, if its packet matches both an interface-leased session and a static session, the user cannot come online.

Recommended actions

Recommended actions

· If such a user exists, verify if the user access interface is configured with remote address dhcp client-identifier with the session-info keyword specified.

¡ If the setting is not configured, execute the remote address dhcp client-identifier with the session-info keyword specified as needed. After the command execution, make the user come online again. If the user fails to come online again, contact Technical Support.

Online users on an interface were logged out because the interface was added to a UP backup profile.

Recommended actions

1. Verify that online users on an interface are logged out because the interface is added to a UP backup profile.

2. Contact Technical Support.

UP mode is standby

Message

UP mode is standby

Possible reasons

In a UP backup network, users could not come online on an interface because the interface was a backup interface.

Recommended actions

1. Bring the users online after the failure is recovered or the switchover is completed.

2. If the problem persists, contact Technical Support.

UP Switch NO IfBackup

Message

UP Switch NO IfBackup

Possible reasons

In a vBRAS CUPS system with UP backup, the backup interface is invalid after a master/backup UP switchover.

Recommended actions

Check the VLAN termination or user VLAN configuration of subinterfaces of the master and backup interfaces. For example, if you configure VLAN termination for VLAN 100 on the subinterface of the master interface, you must also configure VLAN termination for VLAN 100 on the subinterface of the backup interface.

UP Switch Offline

Message

UP Switch Offline

Possible reasons

In a vBRAS CUPS system with UP backup, a user was logged out during a master/backup UP switchover performed when the user was in unstable state (for example, when the user was coming online.)

Recommended actions

Recommended actions

1. Use the display password-control blacklist command in any view to check whether the user is on the blacklist.

2. If the user is on the blacklist, execute the reset password-control blacklist command in user view to remove the blacklisted user.

3. Bring the user online again.

User request

Message

User request

Possible reasons

· IPoE was disabled on the interface.

· L2TP negotiation failed, and a CDN packet was sent to notify the remote end to terminate session negotiation and tear down the session.

Recommended actions

If the user went offline not because the access configuration was disabled, contact Technical Support.

VSRP status change

Message

VSRP status change

Possible reasons

Possible reasons

When an IPoE Web user of the preauthentication domain attempts to come online in the postauthentication domain by inheriting PPPoE user information, the BRAS device denies the Web online request upon receiving the request. The user then uses the inherited information to come online in the postauthentication domain.

Recommended actions

No action is required.

H3C SR8800-X Routers Maintenance Guides-R8530Pxx-6W100

About this guide

General troubleshooting flow

General BRAS troubleshooting procedures by plane

Collecting user information

Collecting information for troubleshooting the PPPoE module

Collecting information for troubleshooting the IPoE module

Collecting information for troubleshooting the L2TP module

Collecting information for troubleshooting the DHCP module

Collecting information for troubleshooting the AAA module

Collecting information for troubleshooting the PPPoE module

Collecting information for troubleshooting the IPoE module

Collecting information for troubleshooting the L2TP module

Collecting information for troubleshooting the DHCP module

Collecting information for troubleshooting the AAA module

Symptom

Common causes

Troubleshooting flow

Solution

Symptom

Common causes

Troubleshooting flow

Solution

Related alarm and log messages

Alarm messages

Log messages

Symptom

Common causes

Troubleshooting flow

Solution

Related alarm and log messages

Alarm messages

Log messages

Symptom

Common causes

Troubleshooting flow

Solution

Symptom

Common causes

Troubleshooting flow

Solution

Symptom

Common causes

Troubleshooting flow

Solution

Symptom

Common causes

Troubleshooting flow

Solution

IPoE static user online failure or abnormal offline event

Symptom

Common causes

Troubleshooting flow

Solution

Symptom

Common causes

Troubleshooting flow

Solution

Symptom

Common causes

Troubleshooting flow

Solution

Appendix A Reasons for user login failures and abnormal logouts

Message

Reasons

Recommended actions

Message

Reasons

Recommended actions

Message

Reasons

Recommended actions

Message

Reasons

Recommended actions

Message

Reasons

Recommended actions

Message

Reasons