1. user request to offline
The users request to get offline and it is normal.
2. PPP echo fail/ARP detect fail/802.1x handshake fail
The three types of reasons belong to failure of handshaking, and they correspond to PPPOE user, VLAN user and 802.1 X users respectively. The root cause lies in that MA5200F sends handshaking packets (including ARP, ECHO, EAP packets)to users, but no response from them is received, so MA5200F thinks the user has gotten offline abnormally, and disconnects the user. The common reasons include drop-off of network cables, abnormal off of terminal, down of link, crash of terminal, congestion of link, CAR of host caused by user virus, etc. For the first four reasons, they are out of control and should be avoided as possible as much. If terminal and link are in normal state, and users drop offline frequently yet, please make sure if traffic at layer 2 network is normal, and if broadcast storm causes layer-2 network to congest. At this point, lots of packets will drop when the terminal PINGs MA5200F (pings users from MA5200).
Solution: If packets are dropped due to CAR from user to host caused by layer2 network congestion or virus from user, the fundamental solution is to optimize the layer 2 network (including virus scanning for client). At the same time, adjusting the handshaking time interval and times of MA5200F could ease the problem temporarily. Noticeably, revision of handshaking time interval and times could not root the problem out; when a user drops offline because of abnormal off, crash or drop-off of cables, the accounting will generate a large gap. The relevant commands include:
VLAN user: [MA5200F]user detect
PPPOE user: [MA5200F-Virtual-Template1]ppp keepalive
DOT1X user: [MA5200F-dot1x-template-1] keepalive retransmit
Others: If the above methods cannot address the problem, you could capture packets to locate the problem; that is, add a HUB between
3. message to client timeout
Once passing dail-up authentication, the user is online continuously; if it sends another request packet for coming online, it will be in negotiation state again, resulting in abnormality. Generally, it should not send a second request, so it can make sure that the client is problematic. The user has been online, but the client sends another PPP negotiation packet, and MA5200F responds it, which point, the problem belongs to this type if the user does not reply a packet.
4. CM IP address alloc fail
Address allocation fails. It is possible that there is no address in address pool, or the domain the user locates at is not assigned with address pool.
Solution: Check the configurations related to address pool.
5. CM Ifnet down
Solution: Check why the port is UP/DOWN, including network cable, working mode of port, etc.
6. WEB user request
WEB user gets offline normally.
If a user feedbacks dropping-offline unexpectedly, and the relevant reason is that heartbeat of WEB authentication user times out. Once the WEB authentication user passes authentication, it will regularly send detection packets (heartbeat) to WEB authentication client to prevent the WEB authentication client from shut-down by the user; if WEB authentication client is shut down unexpectedly, heartbeat packet will not receive reply; at this point, if no response is received for many times, WEB will inform MA5200 user that he is cut for timeout of heartbeat.
Solution: Make sure if the communication between client and WEB server is normal or not, and if layer 2 network discards packets, etc (refer to the way to check failure of handshaking). Check if the client enables VPN service; in some cases, VPN service could make the packets from client be forwarded VPN completely, resulting in failure of heartbeat. If the user is not sensitive to accounting time, you could shut down heartbeat packet at server.
7. LNS clear session
LNS clears SESSION, and LNS disconnects link.
8. AM lease timeout
DHCP lease times out and the packet to continue the lease is not received, and the user is cut.
9. DHCP server nak
DHCP server rejects. Generally, an address has been allocated, but IP/ARP triggering online needs it still.
10. DHCP time out
DHCP server response times out.
11. DHCP declinet
the client side refuses;
12. CM time out
MA5200F is configured with layer 3 WEB authentication, and the user needs IP packet only, so it will cause the user to be authenticated in pre-authentication domain, but it is required for the user to pass WEB authentication if it wants to come online actually. If the user has passed the authentication in pre-authentication domain but has not undergone WEB authentication, it will be cut in five minutes, and the offline reason is cm time out. For other cases, if such kind of offline reason occurs, it is usually caused by that the user terminates the process to access network surprisingly, and further timeout of packet message. This kind of case is not worth to care.
13. Srvcfg cut command
The command line is cut;
14. CM AAA connect check fail
Entries are found inconsistent in checkup; if there is a large deal of such reasons, contact 800 engineers of Huawei, please.
15. Idle cut
The user is cut because of idle. If the traffic of a user within a certain time is less than the value set on MA5200F, MA5200F will cut the user.
Solution: If idle cut is not required, use the undo idle-cut command in the domain to shut down the functionality of idle cut; if it is RADIUS that advertises the configuration data, you could disable RADIUS to send this attribute, or use RADIUS attribute conversion tool at MA5200F to disable idle cut functionality.
16. session time out
Session times out. RADIUS advertises No. 27 attribute which cuts the user offline when the value of session-timeout is 0. The attribute is the time left for a user to access network set by RADIUS.
Solution: make sure why RADIUS advertises session-timeout=0, and if the pre-paid account contains no balance, etc;
17. ppp authentication fail
PPPOE user fails in authentication. It generally results from false user name or password, or false port VLAN, etc.
A user’s failure in real-time accounting causes it being cut-offline. When the user is online, to reduce errors in accounting, MA5200F will send accounting packets to AAA server every a certain time (12 minutes by default); if the accounting packet receives no response within the times configured, MA5200F will regard real-time accounting as failure and will cut the user.
Solution: If the user is authenticated at the local, please make sure if the local bill pool and local FLASH have available room. If TFTP standby server for bill is configured, please make sure if TFTP server works normal, and if billings could back up to TFTP server; if the user is authenticated by RADIUS, please make sure if RADIUS works normal, and if the link to RADIUS is normal, and if RADIUS supports real-time accounting packets. If RADIUS does not support real-time accounting, shut down real-time accounting at MA5200.