No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search


To have a better experience, please upgrade your IE browser.

Knowledge Base

After an ME60 Is Configured with IPoE Authentication, Terminals Frequently Go Offline Unexpectedly

Publication Date:  2019-07-17  |   Views:  191  |   Downloads:  0  |   Document ID:  EKB1100015029


Issue Description

ME60----aggregation switch----access switch---PC

After an ME60 is configured with Layer 2 IPoE authentication, terminals can access the network properly. However, after a period of time, terminals go offline unexpectedly. The terminals can go online again after re-dialup is performed.

The involved configurations are as follows:

radius-server group test
 radius-server authentication 1812 weight 0
 radius-server accounting 1813 weight 0
 radius-server shared-key b$L2Ma6OUV,'0-3!9!^{!WG#t-E=_{I<%%^%#       
 authentication-scheme auth
  accounting-scheme acct
 domain default0
  user-group huawei
  web-server url
  ip-pool huawei
 domain xxxx
  authentication-scheme auth
  accounting-scheme acct
  radius-server group test
  portal-server url
interface GigabitEthernet1/0/2.1
 vlan-type dot1q 1229
 ip address
  access-type layer2-subscriber default-domain  authentication xxxx

Handling Process

1. Locate the causes of the problem that terminals go offline unexpectedly.

[ME60-1]dis aaa abnormal-offline-record mac-address xxxx-xxxx-xxxx
  User name          : xxxx9001
  Domain name        : xxxx
  User MAC           : ****-****-****
  User access type   : IPoE
  User access interface: Eth-Trunk3.32
  User access PeVlan/CeVlan    : 2277/-
  User IP address    :
  User ID            : 140768
  User authen state  : Authened
  User acct state    : Accting
  User author state  : AuthorIdle
  User login time    : 2017-04-14 14:09:00
  User offline time  : 2017-04-14 14:44:36
  User offline reason: AAA with radius server cut command

It can be confirmed that the problem is caused by the cut action delivered by the RADIUS server. Check why the RADIUS server delivers such a cut action.

2. Confirm with the RADIUS server vendor. It is found that the RADIUS server needs to periodically receive user information update packets. The RADIUS server has not received the update packets sent by the BRAS and therefore delivers a cut action. The content of the packets required by the RADIUS server cannot be confirmed currently.

From the perspective of ME60s, terminals send packets associated with authentication requests and accounting requests to the RADIUS server only after authentication is configured. In principle, after authentication succeeds, no packets are sent to the RADIUS server unless a user offline request is received. For ME60s, the only involved action is real-time accounting when the RADIUS server needs to periodically send user update packets. The period for sending real-time accounting packets can be specified on ME60s so that the ME60s can periodically send accounting packets to the RADIUS server.

It is confirmed that the RADIUS server requires the BRAS to send user update packets at an interval of 20 minutes.

There are two options for solving the problem: 1. Disable periodic detection on the RADIUS server. 2. Enable real-time accounting on ME60s and set the period for sending real-time accounting packets to 20 minutes.

The problem is finally solved by disabling periodic detection on the RADIUS server.

Root Cause

The RADIUS server fails to periodically detect user information and cannot receive the user update packets that are periodically sent by the BRAS. Therefore, the RADIUS server issues the action to cut off the involved user.


Disable periodic detection on the RADIUS server.


Periodic user offline is typically considered as caused by a link failure or an authentication server fault. As access gateways, ME60s do not periodically force users to go offline after authentication succeeds. This cut action is not issued by default.