Jump to content
Sign in to follow this  
  • entries
    5
  • comments
    0
  • views
    349

About this blog

Issue Description

 Change the running OptiX OSN 3500 from a main subrack into an extended subrack. Mount the extended subrack to a newly created OptiX OSN 3500. Query the physical slots of the extended subrack. It is found that the boards in the extended subrack fail to be displayed and that the tributary boards in the extended subrack are displayed as off-service on the T2000. 

Alarm Information

Null

Handling Process

1.Check the connection between the main subrack and the extended subrack. It is found that the connection is normal. 
2.Perform warm reset on the SCC board and the AUX boards in the main subrack and in the extended subrack. It is found that the problem persists. 
3.Remove the off-service boards and then insert the boards back to force the boards to perform cold reset. Then, the boards obtain the new slot IDs. The problem is solved. 
 

Root Cause

The possible causes are as follows: 

1.The connection between the main subrack and the extended subrack is faulty. 
2.The SCC board in the main subrack and the AUX boards in the main subrack and in the extended subrack are faulty. 
3.The tributary boards in the extended subrack are not reset and thus the correct slot IDs cannot be obtained. 
 

Suggestions

The following part considers the UXCSB as the cross-connect board of the main subrack and describes the precautions for the connection between the main subrack and the extended subrack.

· Cable connection between the UXCSB and the XCE: The EXA and EXB ports on the UXCSB board in slot 9 are connected to the EXA ports on the XCE board in slots 59 and 60. The EXA and EXB ports on the UXCSB board in slot 10 are connected to the EXB ports on the XCE board in slots 59 and 60. See Figure 1.

· The EXT port on the AUX board in the main subrack is connected to the EXT port on the AUX board in the extended subrack. See Figure 1.

· Cover the J9 jumper on the AUX board in the main subrack with the jumper cap and maintain the J9 jumper on the AUX board in the extended subrack uncapped.

· Do as follows to reconstruct a running main subrack into an extended subrack:

00001. Remove the SCC board, line board, and certain unused tributary boards.

00002. Connect the EXT ports on the two AUX boards and remove the J9 jumper on the AUX board in the extended subrack.

00003. Remove the two cross-connect boards.

00004. Insert two XCE boards instead and connect the two XCE boards to the UXCSB boards in the new main subrack.

After the two cross-connect boards are removed, the extended subrack has no cross-connections. Hence, the tributary boards in the extended subrack are automatically reset. After the J9 jumper is removed from the AUX board, the tributary boards can obtain the new slot IDs (that is, the original ID plus 50). After performing the operations, you need not remove the tributary boards and then insert the boards back again after the configuration.

Entries in this blog

 

How to resplve The Device Does Not Respond to Input from the Keyboard

If you huawei switch S5720 Not Respond to Input from the Keyboard,what should you do, then let me tell you. Fault Description The command line interface of the device suddenly does not respond to input from the keyboard. Possible Cause The device is processing other services and the high CPU usage results in no response to the input from the keyboard. Another user restarts the device or the device restarts at the scheduled time. The device hardware is damaged or a software bug occurs Procedure Check whether any user runs the save or display diagnostic-information command. The command execution results in high CPU usage in a short period during which the device does not respond to input from the keyboard. Wait for a while and check whether the fault is rectified. If the fault persists, go to the next step. Check whether any user restarts the device. Only users of level 3 and higher levels can run the reboot command to restart the device. Check whether any authorized user restarts the device. Log in to the device through the console interface to check whether the frequently changing information is displayed and whether the device starts normally based on the information. If the device starts normally, the fault is rectified after a while. If the device starts abnormally, rectify the fault by referring to The Device Repeatedly Restarts. If no information is displayed or illegible characters are displayed, go to the next step. If the fault persists, the device hardware may be damaged or a software bug occurs. Contact technical support personnel to rectify the fault.

zara

zara

 

When the ODUk SPRing Protection Switching Is Performed by Running External Commands, If the Tributary Board Is Not in Position, the Switching May Fail

Issue Description When the ODUk SPRing protection switching is performed by running external commands, if the tributary board is not in position, the switching may fail.  Alarm Information Null   Handling Process If the tributary board for the westward or eastward services of the ODUk SPRing protection is not in position, performing the switching by running external commands is nonsense. If you really intend to perform the switching by running external commands, you must ensure that the tributary board for services in that direction is in position.  Root Cause In the network shown in the following figure, NE6 is the management node, and services are configured between NE2 and NE6. In addition, the tributary board of NE2 is not in position. 
Under normal conditions, the service flow, indicated by the red real line, is as shown in the figure. When NE6 starts a westward forced switching, NE2 switches from the IDLE page to the eastward switching page. The service flow, indicated by the blue dashed line, is as shown in the figure. 
In the process of the switching, if the tributary board of NE2 is in position, the OTN signal on the protection link is stable and there are no abnormal alarms on the protection channel. But if the tributary board of NE2 is not in position, the OTN signal on the protection link needs to be regenerated by an NS2 board (according to certain Recommendations). The regeneration operation requires a certain period of time. The protection channel may detect abnormal alarms before the OTN signal regeneration is completed and immediately reports an SF alarm, which results in the failure of the forced switching. 

zara

zara

 

EPL service does not work after configuration

Issue Description There are two OSN 3500, we config one EPL service with exterior port attribute is Hybrid, but we can not ping successfully with no VLAN message after configuration.

The GSCC version is 5.21.31.35;
The data service board is N1PEG8;
  Alarm Information NULL Handling Process 1,Creat the service firstly and then change the port attribute to Hybrid secondly, the service will be ok.

2,If the problem has happened, we should change the port attribute to ACCESS and change it to Hybrid again, then the service will be ok.

3,Change the UNI port attribute from Hybrid to ACCESS for both resource node and sink node(of course it should accord with the service need).

This problem exsit for all the V2R11 versions of NG-SDH, we can upgrade to the V2R11C00SPC300  and its later versions to solve this issue ultimately.  Root Cause 1, We recur this problem in lab, if we config the UNI port attribute firstly and then creat the EPL service secondly, then the service is not successful. If we creat the ethernet special line service firstly and then change the UNI port attribute to Hybrid, creat EPL service again, the new EPL service is still not successful.

2,Analysis by capturing packet, we find that if we set the port attribute to  Hybrid firstly and the creat the EPLsecondly, the default VLAN will not be stripped when the message with default VLAN pass through the port ,so the service can not be successful.
  Suggestions Not only EPL servcie has this problem, the other ethernet service also has this problem, if you finish config one ethernet service and the external port attribute is Hybrid, but you can not ping successfully with no VLAN ID massege, please refer to this case.

zara

zara

 

VCAT_LOA was appearing on N2EFS4 board due to the inconsistent of SNCP state

Issue Description There is one Ethernet service between two NEs (OSN7500 having software version of 5.21.18.53). Service type is Ethernet Line Service of 2Mbps. Moreover there is configured SNCP between two different lines on SDH layer to protect 2Mbps Ethernet Line Service in case of dual fiber break. The SNCP service is configured NON-Revertive for beow topology.

NE1-NE2-NE3-NE4 (Working path)
NE1-NE5-NE6-NE4 (Protection path)

  Alarm Information ALM_GFP_dLFD
VCAT_LOA
VCAT_LOM_VC12
LP_SLM_VC12 Handling Process After switching the service on NE4 to 'Working Channel' by SNCP Service Control, alams were cleared at the same time. Now the SNCP state becomes consistent and no service alarms are present. Root Cause Below points were ensured during troubleshooting and found normal in status

1) The SNCP status was normal for both NE1 and NE4
2) Traffic was not down during these alarms
3) No switching was present for the Ring and SNCP

Later it was found that SNCP service was running on 'Working Channel' on NE1 and 'Protection Channel' on NE4 due to which the trail was showing alarms. Which means that SNCP state was inconsistent. Moreover the traffic was not down during these alarms. Suggestions Always make sure that SNCP is in consistent state for both NEs where it is created. Otherwise the signal label to be received at local station is inconsistent with that to be transmitted at the opposite station.

zara

zara

 

E1s total affectation if services capacity exceed the bandwidth configured in RTN910

Issue Description In the RTN 910 V1R1 Huawei engineer configured 16 CES services with the U2000 Web LCT V100R002C01SPC003 correctly and began to connect tributaries one by one in the DDF. First BTSs were working normally but after engineer connect the E1 in 14 port, services in all ports got interrupted. Alarm Information CES_LOSPKT_EXC Handling Process To solve the problem it is necessary to set a modulation and a IF bandwidth according with the capacity to be configured. In this case a 32QAM / 28MHz work mode is enough to configure 16 CES services. Root Cause After service affectation field engineer procedure to verify the RTN910 configuration as follows:


- Check the CES service configuration. 16 E1s were well configured in both RTNs
- After verify the alarm (CES_LOSPKT_EXC) reported by RTN in both sides engineer check the modulation and IF bandwidth. Modulation was in 32QAM and IF bandwidth in 7 MHz.
- With the 32QAM and 7 MHz total bandwidth is 25 Mb/s and total bandwidth services configured were 32 Mb/s causing an exceed of packets and hence lost of services

  Suggestions Verify the engineer design and the bandwidth capacity in the IF parameters to assure services don’t exceed the limit supported 

zara

zara

Sign in to follow this  
×

Important Information

By using this site, you agree to our Terms of Use.