Showing posts with label OptiX OSN 8800. Show all posts
Showing posts with label OptiX OSN 8800. Show all posts

Tuesday, September 13, 2016

Active/Standby Switching Cannot Be Performed After an SCC Board of the OptiX OSN 8800 Is Replaced

Active/Standby switching cannot be performed after an SCC board of the OptiX OSN 8800 is replaced.

Fault Type

System and Communication Unit

Symptom

An OptiX OSN 8800 NE at an office reports a file loss alarm. The TN51SCC board on the NE is then replaced with a new SCC board with NE software of a later version. The BIOS of the new SCC board, however, cannot be synchronized with that of the other SCC board on the NE. After the new SCC board is reset, the BIOS synchronization still fails and the active/standby SCC switching cannot be performed.
After the new SCC board is replaced with a normal SCC board from another NE, the alarm is cleared and the active/standby switching can be performed successfully.
After the new SCC board is inserted to one normal NE, active/standby switching also cannot be performed.
The versions of the SCC board running on the live network and the new SCC board are as follows:
  • Version of the new SCC board: 5.51.5.26
  • Version of the SCC board running on the live network: 5.51.4.24

Cause Analysis

The possible causes of the fault are as follows:
The version of the new SCC board is later than that of the other SCC board on the NE. The NE does not support smooth downgrade of the NE database and thus the new SCC board cannot function properly.

Procedure

  1. Perform the following operations to identify the problem:
    1. Check the software version of the new SCC board and find that the version is 5.51.5.26.
    2. Attempt to downgrade the software of the new SCC board to 5.51.4.24 by inserting the new SCC board in a slave subrack.
    3. Insert the new SCC board back to the master subrack.
    4. Perform active/standby switching. The switching fails.
  2. Set the jumpers on the new SCC board and insert it to the slot of the old SCC board so that the database of the new SCC board is cleared automatically.
  3. After the new SCC board is started, remove it. In addition, remove the jumper caps on the board. After that, re-insert this SCC board back to the slot. For information on how to set jumpers on an SCC board, see "Replacing the SCC Board" in the Parts Replacement for OptiX OSN 8800 V100R002C02.

Result

The problem is resolved.

Reference Information

Conclusions and suggestions for this case are as follows:
Clear the databases of the new SCC board before the replacement. Then, replace an existing SCC board on an NE with the new SCC board. For more information, see "Replacing the SCC Board" in the Parts Replacement for OptiX OSN 8800 V100R002C02. After the new SCC board goes online, synchronization of software and database between the active SCC board and the new SCC board is performed automatically. When software and database synchronization is complete, perform active/standby SCC switching.


MORE BLOG:

During the Rerouting in the ASON Network, the Protection Switching Time May Exceed the Specification Value

Wednesday, August 24, 2016

Secondary GNE Becomes Unavailable After a Change of the Maximum Number of Route Hops of an NE

The actual maximum number of route hops of an NE is greater than the set maximum number of route hops. Therefore, the secondary GNE becomes unavailable.

Product

OptiX OSN 3800
OptiX OSN 1800
OptiX BWS 1600G
OptiX Metro 6100
OptiX Metro 6040

Fault Type

NE Offline

Symptom

NE28 and NE29 are unreachable to the T2000 after the primary GNE is switched to the secondary GNE (NE111). That is, the secondary GNE becomes unavailable.

Cause Analysis

The maximum number of route hops of NE28 or NE29 is set to 20. Actually, the number of route hops between NE28 (or NE29) and the GNE is greater than 20. As a result, a standby route is not available between NE28 and NE29 and communication between the two NEs is interrupted.

Procedure

  1. Determine that the SCC boards and NE software of the two NEs function normally and that the communication parameters are set correctly, considering that NE28 and NE29 are reachable to the T2000 when they are managed by the primary GNE.
  2. Query the maximum number of route hops of each NE and find that the number is 20, which is smaller than the actual number of route hops. This leads to a failure to search for a standby route.
  3. Set the maximum number of route hops to the default value 64. The problem is resolved.

Result

The problem is resolved.

Reference Information

The common causes of the fault are as follows:
  • The communication parameters, for example, NE ID, subnet mask, and FEC mode, are set incorrectly.
  • The SCC board of the NE is reset repeatedly.
  • The network is unstable because the number of connected NEs in auto ECC extension mode exceeds the permitted value.
MORE BLOG:

Tuesday, August 23, 2016

Service Provisioning Fails on an LHP Network, The OTU2_LOF Alarm Is Reported

The service provisioning fails on an LHP network cause by the connectors on the RPC are burnt, the OTU2_LOF alarm is reported.

Product

OptiX BWS 1600G, OptiX OSN 6800, OptiX OSN 8800

Fault Type

OTU2_LOF

Symptom

During commissioning of a long hop (LHP) network, the OTU2_LOF alarm is reported and service provisioning fails. 

Cause Analysis

To locate this type of fault, check the optical power of signals. Most exceptions are relevant to the optical power. Before locating this type of fault, make correct power budget for each section. Therefore, the fault can be avoided.
The possible causes of the fault are as follows:
  • The E2000 fiber jumpers are burnt.
  • Connectors on boards such as the ROP and RPC are burnt, or the laser is not enabled or fails.
  • The DCM or FOA is mis-placed on the line.

Procedure

  1. When the fault occurs, check whether the transmit optical power and receive optical power are normal.
  2. If the receive optical power of the OA at the transmit end is abnormal, check whether the gain of the backward RPC and the gain of the ROP are normal. If the gain of the backward RPC is higher than 10 dB, it indicates that the backward RPC is normal; if the total gain of both the backward RPC and ROP is higher than 30 dB, it indicates that the backward RPC and ROP are normal. Otherwise, further check whether the E2000 fiber jumpers or connectors on the RPC are normal.
  3. Use a microscope to check the connectors of the fiber jumpers on the E2000. If the connectors are dirty, clean the connectors. If the connectors are burnt, replace the fiber jumpers.
  4. Check whether the gain of the laser on the RPC is abnormal. Check whether the pump laser on the RPC is enabled. If the laser is not enabled, enable it and then check the gain of it.
  5. If the gain is still abnormal at this time, check whether the pump optical power equals the pre-set value. If the pump optical power is lower than the pre-set value, use a microscope to check the connectors on the RPC. If the connectors are normal, it indicates that the laser fails.
  6. Based on the preceding analysis, it is determined that the root cause of the fault is that the connectors on the RPC are burnt. Due to burnt connectors, the Raman gain of the RPC is insufficient and service provisioning fails.

Result

The problem is resolved.

WDM-Side Pre-FEC BER Changes Drastically

Because the accumulated PMD over a 10G line exceedes the design value, the WDM-side pre-FEC BER changes drastically.

Product

OptiX Metro 6100
OptiX Metro 6040

Fault Type

Bit Error
PMD Abnormity

Symptom

During expansion of WDM equipment on the network L, the pre-FEC BER in three 10G channels for expansion changes drastically. Within a day, the pre-FEC BER changes from 10–6 to 10–11.
The newly deployed 10G services report a transient alarm indicating that the pre-FEC BER crosses the threshold. The existing 2.5G services are normal without any bit error or alarm.

Cause Analysis

Compared with low-rate services such as 2.5G services, high-rate services such as 10G or 40G services have higher requirements for specifications of cables. For example, if the accumulated PMD is higher than the tolerance value, a large non-linear cost will be introduced. As a result, system performance deteriorates.
The possible causes of the fault are as follows:
  • The line optical power fluctuates, with a deviation greater than 3 dB.
  • The board at the transmit end is faulty.
  • The board at the receive end is faulty.
  • The quality of line cables deteriorates (for example, PMD is excessively high).

Procedure

  1. The collected data indicates that the line optical power does not change drastically.
  2. Replace the relevant board, but the BER still changes drastically. Therefore, the fault is irrelevant to the board.
  3. The data on the line collected by using the OTDR in a test indicates that reflection is lower than or equal to -27 dB.
  4. Therefore, it is suspected that the line PMD exceeds the tolerance of a 10G system. The result of an on-site test indicates that the accumulated PMD over a 10G line reaches 12 ps, exceeding the design value. After the cables are replaced, the fault is rectified.

Result

The problem is resolved.