A：
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 port of
MA5200F and the switch, or
configure port mirror for the switch to check the interaction process of
handshaking packets between MA5200 and client side as to locate the problem.
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
That the
port of
MA5200F which is accessed by the
user is down causes dropping-offline;
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.
18. AAA_RTACCTFAIL
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.
