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>

Reminder

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

upgrade

The steps how to restore the communication to an not-reachable OSN1500 again, when T2000 NMS, T2000 LCT and Navigator fail to connect

Publication Date:  2012-07-25 Views:  59 Downloads:  0
Issue Description
The communicationr to/from an OSN1500 NE with two CXL16(GSCC) were lost. T2000 NMS could not manage the NE anymore. Field engineer drove on-site to connect with LCT and/or Navigator, but also this failed. After pinging this NE also failed we exchanged the AUX board, warm&cold reseted the CXL16 board 
one by one we saw that this is a very strange issue, because it did not help.
Alarm Information
Null
Handling Process
Try to connect locally with your laptop and a T2000, LCT or Navigator. If all three methods fail and you also can not ping the OSN1500 NE IP but you can open a telnet-session you should follow below steps to be able to restore it in a very fast way.
1) open the cmd-window and enter "telnet 192.168.0.82" // or 192.168.0.83 (you have to use the COM-port on AUX board for telnet)
2) afterwards you should enter "ifShow" to query that OSN1500 IP // in our case it was 10.224.70.16
3) Due to the fact that we saw there is something wrong with the communication parameters but we can not change it because no T2000 or navigator was able to
 connect, we had to use the telnet command for changing the IP: "dwSaveSPIP(0x81090010)"  // =129.9.0.16
4) After initialization of the new IP you should be able to ping 129.9.0.16 // now you have to use ETH-port on AUX board
5) Now you can modify the IP to its orignal one // in our case 10.224.70.16
6) After initialization of the GSCC we could again manage this NE by T2000 and so on.
No service-interruption occured and NE was reachable again after IP changing!
Root Cause
The IP address of that OSN1500 was still the same but it was not possible to ping it // because "ifShow" output of IP was correct (in our case 10.224.70.16)
Suggestions
After replacing and reseting few boards we could not get any feedback from the NE. Only the telnet-session worked and that is why I think that this case can help all other engineers when they face this issue, to ensure that they do not have to troubleshoot several
 hours without any idea. This telnet command is also for future troubleshooting very useful! "dwSaveSPIP(0x81090010)"   // it is 129.9.0.16

END