Showing posts with label OSN3500. Show all posts
Showing posts with label OSN3500. Show all posts

Friday, October 21, 2016

E1 Service Interruption Caused by Different Timeslot Numbering Schemes (ITU-T G.707 and ITU-T G.709)

When different devices or networks are interconnected with each other to provide services, part of the services are interrupted if different timeslot numbering schemes are adopted. After a timeslot numbering scheme is adopted, the fault is rectified.

Fault Type

  • Configuration problem
  • Device interconnection failure
  • Service interruption

Symptom

Two transmission devices from different vendors are interconnected with each other, and 20 timeslots of one STM-1 are adopted to transmit E1 services. When the services are configured, it is found that seven E1 services of timeslots 1, 4, 7, 10, 13, 16 and 19 are normal, and 13 E1 services of timeslots 2, 3, 5, 6, 8, 9, 11, 12, 14, 15, 17, 18 and 20 are interrupted.

Cause Analysis

Company A uses a Huawei device, which adopts the ITU-T G.707 timeslot numbering scheme. Company B uses the device of a competitor, which adopts the ITU-T G.709 timeslot numbering scheme.
 NOTE:
The sequences of timeslots 1, 4, 7, 10, 13, 16, and 19 in the two timeslot numbering schemes (ITU-T G.707 and ITU-T G.709) are the same, but the sequences of timeslots 2, 3, 5, 6, 8, 9, 11, 12, 14, 15, 17, 18 and 20 in the two timeslot numbering schemes are different, thus causing the service interruption.

Procedure

  1. According to the timeslot sequence from 1 to 20, configure the E1 services on the device of company A.
  2. Configure the services on the device of company B. Table 1 shows the mapping of timeslot numbers.
    Table 1Mapping of timeslot numbers between the devices of companies A and B
    Company
    Timeslot Number
    A
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    B
    1
    22
    43
    4
    25
    46
    7
    28
    49
    10
    31
    52
    13
    24
    55
    16
    37
    58
    19
    40
     NOTE:
    You can configure the E1 services on the device of company A, and then according to the timeslot mapping, configure the services for corresponding timeslots on the device of company B. For the corresponding timeslots, see Table 1.

Reference Information

  • The ITU-T G.707 timeslot numbering scheme adopts the sequential mode, which is also called Huawei mode, as shown in Figure 1. The numbering scheme is as follows: VC-12 number = TUG-3 number + (TUG-2 number - 1) x 3 + (TU-12 number - 1) x 21.
  • The ITU-T G.709 timeslot numbering scheme adopts the interleaved mode, which is also called Lucent mode, as shown in Figure 1. The numbering scheme is as follows: VC-12 number = (TUG-3 number - 1) x 21 + (TUG-2 number - 1) x 3 + TU-12 number.
Figure 1 ITU-T G.707 timeslot numbering



Friday, September 23, 2016

SHDSL Alarm Profile Configuration----shdsl alarm-profile delete

Function

This command is used to delete an SHDSL alarm profile. When an SHDSL alarm profile is no longer useful, you can run the command to delete it. After the SHDSL alarm profile is deleted, the configuration data is deleted and cannot be restored.

Format

shdsl alarm-profile delete profile-index

Parameters

Parameter Description Value
profile-index Indicates the ID of an SHDSL alarm profile. Numeral type. Range: 2-99.

Modes

Global config mode, SHDSL mode, OSN 3500, OSN 7500

Level

Operator level

Usage Guidelines

  • Run the config command to enter global config mode, and then run the interface shl command to enter SHDSL mode.
  • When deleting an SHDSL alarm profile, pay attention to the following points:
    • The default profile (profile 1) cannot be deleted.
    • The profile in use cannot be deleted.

Example

To delete SHDSL alarm profile 4, do as follows:
huawei(config)#shdsl alarm-profile delete                           
{ profile-index<U><2,99> }:4                                                     
                                                                                
  Command:                                                                      
          shdsl alarm-profile delete 4  

System Response

  • The system does not display any message after the SHDSL alarm profile is deleted successfully.
  • For more information about the error message that the system displays against a command entered with incorrect syntax.
MORE BLOG:

Monday, September 12, 2016

Networkwide Conflict of MAC Addresses Caused by Incorrect Configuration of Protocol Converters from Other Vendors

The MAC addresses of the protocol converters from other vendors are set to the same value. As a result, the networkwide conflict of MAC addresses occurs after the devices from Huawei are interconnected with the devices from other vendors. This problem is solved by changing the MAC addresses of the protocol converters to different values.

Product

Fault Type

Equipment interconnection failure

Symptom

A chain consists of the OptiX OSN equipment and the Ethernet boards configured on the NEs are the N4EFS0 and N1ETF8 boards. EPLAN services are configured on the chain because all other sites can communicate with the central site. After the OptiX OSN equipment is interconnected with the protocol converters from other vendors, the interconnected interface on the OptiX OSN equipment does not report any alarm, but the monitoring systems of other vendors detect frequent service interruptions.

Cause Analysis

Possible causes of the problem are as follows:
  1. Service configuration is incorrect.
  2. Protocol converters are faulty.

Procedure

  1. Cause 1: Service configuration is incorrect.
    1. Check the service configuration and confirm that the service configuration is correct.
  2. Cause 2: Protocol converters are faulty.
    1. On the NMS, perform RMON performance tests and find that the reception of packets at the receive port is interrupted frequently.
    2. Check the original data of the protocol converters and find that all protocol converters have the same MAC address.
    3. Change the MAC addresses of the protocol converters to different values. Then, the problem is solved.

Related Information

When configuring Ethernet services, you need to analyze the information about the interconnected equipment. Configure different Ethernet services based on different equipment information and service requirements.


MORE BLOG:

Prewarning for ARP Entry Aging Failures on MxU


Thursday, September 1, 2016

Objects that Block the Fan Cause the Device to Report the FAN_FAIL Alarm

The device reports the FAN_FAIL alarm. After the fan is checked, it is found that some objects block the fan board. After the objects are removed, the fan works in the normal state.

Fault Type

Others

Symptom

When the OptiX OSN 1500 is being commissioned, it is found that the fan cannot work in the normal state. The device reports the FAN_FAIL alarm.

Cause Analysis

Fan Failure

Procedure

  1. Remove the fan from the subrack. It is found that some objects block the fan.
  2. Remove the objects and install the fan. The fan can work in the normal state.
  3. Query the NE alarms on the NMS. It is confirmed that no alarm is generated, and the FAN_FAIL alarm is cleared.

Reference Information

When the fan is faulty, check whether some objects block the fan.
If no object blocks the fan, replace the fan board.

MORE BLOG:

When Install SLQ4 board on slot 1 to slot 4 in OSN 3500?

LCAS Negotiation Abnormal if Bound Paths Configured Prior to Cross-Connect Service

When the LCAS function is not enabled on either the source NE or the sink NE, LCAS negotiation faults arise and the LCAS configuration fails if the bound path is configured before the cross-connect service is configured. You can rectify the fault by deleting the existing configurations at both ends and enabling the LCAS function at both ends.

Products

Fault Type

  • LCAS
  • Ethernet fault

Symptom

For the point-to-point NE A and NE B, the LCAS function is enabled at NE A but disabled at NE B. After the bound paths are configured for the data processing boards at both ends and the cross-connect service is configured from the data processing board to the line board, LCAS negotiation at NE A becomes abnormal, that is, all the timeslots are deleted or only one timeslot remains.

Cause Analysis

The fault arises owning to the version and working principles of the LCAS function. Hence, the following situations should be prevented:
  • The LCAS function is disabled at one end.
  • The bound paths are configured before the cross-connection service is configured.

Procedure

  1. Query the status of the LCAS function at both ends, and ensure that the function is enabled at both ends.
  2. Query the paths bound at both ends, and delete the existing configurations.
  3. Query and delete the cross-connect service configured between the data processing board and the line board.
  4. Configure the cross-connect service between the data processing board and the line board, and then configure the bound paths. The alarm disappears, and the troubleshooting is complete.
MORE BLOG:

Tuesday, August 30, 2016

Logical Board of SLQ16 Cannot Be Added on T2000

The logical board of the SLQ16 cannot be created on the T2000. This fault is rectified after the logical board of the cross-connect board is changed.

Fault Type

Others

Symptom

A customer fails to add the logical board of the SLQ16 on the OptiX OSN 3500, and the customer mentions that the cross-connect board is changed from the UXCSA to the SXCSA on site.

Cause Analysis

The SLQ16 is applicable only to the OptiX OSN 3500 of 200 Gbit/s cross-connect capacity. If the cross-connect capacity decreases to 40 or 80 Gbit/s, the SLQ16 fails to work normally. The SXCSA has the board version replacement function. If the original logical board is the UXCSA, the system considers that the cross-connect board is the UXCSA by default, rather than the SXCSA. As a result, the logical board of the SLQ16 cannot be added.

Procedure

  1. Query the physical and logical boards in slots 9 and 10 on the T2000. All the physical and logical boards are the UXCSA.
  2. This is because the customer does not change the logical cross-connect board after the replacement of the physical cross-connect board. Change the logical cross-connect board to the SXCSA. Then, the logical board of the SLQ16 is added successfully.

Tuesday, August 2, 2016

NG-SDH Device Cannot Identify the G.811 Clock Quality

When the NG-SDH device is connected to the BITS clock source, the NG-SDH device cannot identify the clock quality. After the specified clock quality is set to a proper level, the fault is rectified.

Product

NG-SDH, OSN 3500

Fault Type

Synchronization clock loss

Symptom

When the NG-SDH device is connected to a BITS clock source (the clock source quality is G.811 clock quality), the NG-SDH device cannot automatically extract the clock configuration to identify the clock quality. When the clock quality is queried through the NMS, it is found that the clock source for synchronization is unavailable.

Cause Analysis

The clock quality of the device has a low priority. The BITS clock source quality cannot be identified in the phase-locked loop.

Procedure

  1. In the main topology of the NMS, right-click the NE to be set, and then choose NE Explorer.
  2. Choose Configuration > Clock > Clock Subnet Configuration from the Function tree.
  3. On the Clock Quality > Clock Source Quality tab, select External Clock Source.
  4. In the Configuration Quality field, right-click, and then choose G.811 Clock Signal.
  5. Click Apply.
  6. After the device is set to be synchronized with the external clock source, in the Configuration Quality field, right-click, choose Automatic Extraction, and then click Apply.
     NOTE:
    Querying clock synchronization status
    1. In the NE Explorer, choose an NE. Choose Configuration > Clock > Clock Synchronization Status from the Function Tree.
    2. Click Query to query the clock synchronization status from the NE.
  7. Click Query, and confirm that the device can identify the clock quality in the Clock Source Quality.
     NOTE:
    If the queried result in step 7 is that the synchronization clock source is unavailable, set the configuration quality to G.811 Clock Signal.

Reference Information

The troubleshooting method of the device clock is as follows:
Determine whether the extended SSM protocol is enabled on the device. If the extended SSM protocol is not enabled, enable the protocol and specify the clock IDs of the external and internal clock sources. Make sure that the clock IDs in the subnet are unique.


How to do when Occasional Hot Patch Installation Failures?

Interconnection Between Optical Interface Boards of Devices Fails

The optical interface board (namely, N1SF64) of the OptiX OSN 7500 and the optical interface board (namely, A1SF64) of the OptiX 10G (Metro 5000) support different protocols. In this case, when the two boards are interconnected with each other, the service fails. After two optical interface boards that support the same protocol are interconnected, the service runs normally.

Fault Type

  • Device interconnection failure
  • BEFFEC_EXC
  • PLL_FAIL

Symptom

The optical interface board (namely, N1SF64) of the OptiX OSN 7500 and the optical interface board (namely, A1SF64) of the OptiX 10G (Metro 5000) support different protocols, which causes the service failure after the two boards are interconnected.

Cause Analysis

The N1SF64 board supports the ITU-T G.709 protocol, which cannot be interconnected with the A1SF64 board that supports the ITU-T G.975 protocol.

Procedure

  1. Use an optical fiber to connect two N1SF64 boards.
  2. Verify the boards on the NMS. It is found that the service is normal and no alarm is generated.
  3. Use an optical fiber to connect the N1SF64 board to the A1SF64 board.
  4. Verify the boards on the NMS. It is found that the boards cannot work in the normal state. Query the NE alarms. The results are as follows:
    • BEFFEC_EXC
    • PLL_FAIL
  5. Replace the board to ensure that the two optical interface boards provide the same rate and support the same protocol. Then, the service is normal, and no alarm is generated.

Reference Information

Before the network commissioning, you must determine whether the protocol adopted by the board supports the interconnection. If the protocols of the two boards to be interconnected do not support the interconnection, the service fails when the interconnection is performed forcibly.



NE Configuration Loss Due to Disabling of the Automatic and Periodic Database Backup Functions on MSTP Products

Friday, July 29, 2016

Different Definitions of Serial Bytes Cause Failure of Interconnection Between OptiX OSN Equipment and OptiX Metro Equipment

When the OptiX OSN equipment and OptiX Metro equipment are interconnected, broadcast data services are available only if broadcast data ports are interconnected correctly.

Product

Fault Type

Equipment interconnection failure

Symptom

The S1 port on the OptiX OSN equipment is interconnected with the S1 port on the OptiX Metro 1000 to transmit a broadcast data service. The broadcast data service is however unavailable.

Cause Analysis

The OptiX equipment uses four unused overhead bytes to transmit broadcast data services.
The broadcast data ports on the OptiX OSN equipment are defined as follows:
  • For the OptiX OSN equipment, the Serial 1 byte is defined as the first unused byte following the D3 byte in the SDH RS overhead bytes. Generally, the Serial 1 byte corresponds to the S1 port.
  • For the OptiX OSN equipment, the Serial 2 byte is defined as the second unused byte following the D3 byte in the SDH RS overhead bytes. Generally, the Serial 2 byte corresponds to the S2 port.
  • For the OptiX OSN equipment, the Serial 3 byte is defined as the second unused byte following the D12 byte in the SDH MS overhead bytes. Generally, the Serial 3 byte corresponds to the S3 port.
  • For the OptiX OSN equipment, the Serial 4 byte is defined as the first unused byte following the D4 byte in the SDH MS overhead bytes. Generally, the Serial 4 port corresponds to the S4 port.
The broadcast data ports on the OptiX OSN equipment are defined as follows:
  • For the OptiX Metro equipment, the Serial 1 byte corresponds to the F2 byte and is defined as the second unused byte following the D12 byte in the SDH MS overhead bytes. Generally, the Serial 1 byte corresponds to the F2 port.
  • For the OptiX Metro equipment, the Serial 2 byte corresponds to the X1 byte and is defined as the first unused byte following the D4 byte in the SDH MS overhead bytes. Generally, the Serial 2 byte corresponds to the COM2 port.
  • For the OptiX Metro equipment, the Serial 3 byte corresponds to the X2 byte and is defined as the first unused byte following the D3 byte in the SDH RS overhead bytes. Generally, the Serial 3 byte corresponds to the COM3 port.
  • For the OptiX Metro equipment, the Serial 4 byte corresponds to the X3 byte and is defined as the second unused byte following the D3 byte in the SDH RS overhead bytes. Generally, the Serial 4 byte corresponds to the COM4 port.
The correspondence relationships between the serial ports on the OptiX OSN equipment and the OptiX Metro equipment are as follows:
  • The Serial 1 byte on the OptiX Metro equipment corresponds to the Serial 3 byte on the OptiX OSN equipment.
  • The Serial 2 byte on the OptiX Metro equipment corresponds to the Serial 4 byte on the OptiX OSN equipment.
  • The Serial 3 byte on the OptiX Metro equipment corresponds to the Serial 1 byte on the OptiX OSN equipment.
  • The Serial 4 byte on the OptiX Metro equipment corresponds to the Serial 2 byte on the OptiX OSN equipment.
The analysis shows that the broadcast data service is unavailable due to incorrect interconnection between the broadcast data ports on the OptiX OSN and OptiX Metro equipment.

Procedure

  1. Re-configure the broadcast data service according to the correspondence relationships between the broadcast data ports on the OptiX OSN equipment and OptiX SDH equipment.