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>


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


NE Panel Cannot Be Opened on the Client Because of Faults in LAN Where the SUN Server Is Located

Publication Date:  2012-07-25 Views:  72 Downloads:  0
Issue Description
When you open the DSLAM panel on the client, nothing is displayed or a message is displayed indicating that the device information cannot be obtained.
The networking mode is as follows:
SUN server � S6509 � GSR � GSR � MA5200G � S8500 � client PC. 
Alarm Information
Handling Process
1. Check the versions of the N2000 BMS and the device. The versions are normal and can be used in other areas.
2. The problem may be traced to errors in a single NE. It is found through tests that the problem occurs to almost all DSLAM NEs. The failure point is at random.
3. Check the NE daemons. The daemons work normally and the restart count for each NE daemon is 0. The database and space logs are normal. No alarm indicates the full-space status. Synchronize the NE daemons and restart the N2000 BMS server. The problem persists.
4. When performing operations on the NEs through the client, the processes of the server are invoked. Directly log in to the client on the server. The problem does not occur. Connect the PC directly to the SUN server, the client connection is normal. Hence, the problem can be traced to the client or links.
5. Uninstall the client and then install the client again. The problem persists. The client may be attacked by virus. Connect another PC to the server. The problem persists, the server responds slowly during the connection, and an alarm occurs indicating that certain data is missing.
6. Directly ping the server on the client. No packet is lost. But when the ping packets carry 1024 Bytes or more, alarms occur indicating that there are packet loss and repeated addresses.
7. The problem is located. If you use software to capture packets on the client when the client is connected to the sever, certain packets are intercepted. After understanding the networking structure, perform ping tests to each component of the network by layer. When you ping the server from the connected S6509, certain packets are lost and an alarm occurs indicating that there are repeated addresses.
Check other clients on the S6509. The fault is traced to that a VIP client sends repeated packets because of being attacked by viruses. Disable the port of the client and the problem is solved.
The results of the ping tests are as follows:
32-byte packets:
Reply from bytes=32 time=1ms TTL=255
Reply from bytes=32 time=1ms TTL=255
Reply from bytes=32 time=1ms TTL=255
Reply from bytes=32 time=1ms TTL=255
1024-byte packets:
Reply from bytes=1024 time=10ms TTL=255(DUP)
Reply from bytes=1024 time=500ms TTL=255
Request timed out
Reply from bytes=1024 time=20ms TTL=255(DUP)
Reply from bytes=1024 time=300ms TTL=255
Request timed out
Request timed out 
Root Cause
The problem may be traced to the following causes:
1. The versions of the N2000 BMS and the device are not compatible.
2. The link fault makes the communication between the N2000 BMS and the device abnormal.
3. The daemon processes of the N2000 BMS are faulty.
4. The N2000 BMS client is faulty.
5. The connections are faulty between the N2000 BMS server and client.
6. Other causes. 
1. Faults usually occur on the client. When a fault occurs, you need to log in to the client on the server to locate the fault. The fault can be traced to the daemon processes, client, or links.
2. When you ping the server on the client and no packet is lost, you need to verify whether the ping packets with 1024 Bytes are normal. In this case, the packets with default 32 Bytes are normal, but the system generates alarms when the packets carry 1024 Bytes.