Thursday, June 30, 2016

After receiving an ICMP Request packet, a switch does not send it to the ICMP protocol stack but directly returns an ICMP Reply message. This process is called fast ICMPM reply. Switches cannot accurately calculate the delay or jitter of ping packets that require high real-time performance. The protocol stack adds the sending and receiving timestamps to ping packets. The packets need to enqueue frequently between the protocol stack and hardware. This task switching cannot ensure real-time performance of timestamps. In versions earlier than V100R006, fast ICMP reply is a common task. When a switch processes a large volume of service traffic, the reply delay is long due to task switching. In V100R006 and later versions, fast ICMP reply is a super task with a high priority. In most cases, the reply delay is about 1 ms. The actual delay depends on the CPU usage and is shorter than 100 ms. NOTE: By default, box switches have fast ICMP reply enabled in all versions.

The default aging time of ARP entries is 20 minutes. You can run the arp expire-time command to change the aging time.
You can also change the number of ARP probes by running the arp detect-times command. The default number of ARP probes is 3.
When the aging time of an ARP entry expires, the device sends a probe packet to the corresponding IP address every 5 seconds. If the device does not receive any response after the specified number of probes, it deletes the ARP entry.
For example, the aging time of ARP entries is set to 60s and the number of ARP probes is set to 6.
After 60s since an ARP entry is generated, the device sends an ARP probe every 5s. If the device does not receive any response after sending six probes, it deletes the ARP entry. Therefore, the actual aging time of the ARP entry is (60 + 6 x 5) = 90s.
NOTE:
For V100R002 version, the S2700/S3700/S5700/S6700 supports the 1/2 probe time and 3/4 probe time. The numbers of probes on the two time points are both 3 and cannot be changed. For example, if the aging time is 20 minutes (1200s) and the number of ARP probes is 6, the SS2700/S3700/S5700/S6700 sends three ARP probes at an interval of 5s after 10 minutes. After 15 minutes, the S2700/S3700/S5700/S6700 also sends three ARP probes at an interval of 5s. After 20 minutes, the S2700/S3700/S5700/S6700 sends six ARP probes at an interval of 5s. If the S2700/S3700/S5700/S6700 does not receive any response, it deletes the ARP entry.


More blog:

Why Automatical configuration backup cannot work on S5700

Posted by at No comments:
Labels: , , ,

Failing to Add ATM Connections into a Protection Group

After two connections are created, they cannot be added into a protection group. Hence, you need to configure the sink-source relation of the protection group.

Product

Fault Type

Equipment_Interconnection_Fault

Symptom

After creating two connections, you fail to add them into the protection group.

Cause Analysis

  • For 1+1 protection type:
    • In the case of source protection, the working and protection links must have the same sink but different sources.
    • In the case of sink protection, the working and protection links must have the same source but different sinks.
    • In the case of source + sink protection, the working and protection links must have different sinks and different sources.
  • For 1:1 protection, the working and protection links must have different sinks and different sources.

Procedure

  1. Determine the relation between the source and sink of the protection group. After changing the connections, add them into the protection group again.

Reference Information

None.


How to do when Failing to Connect the 155 Mbit/s Optical Port on the Router of Company C

Posted by at No comments:
Labels: , ,

Service Interruption After Enabling the Shaping Function of the N1EMS4 Board

After the shaping function of the N1EMS4 board is enabled for egress port queues, the services are interrupted.

Product

Fault Type

  • RPR
  • Ethernet fault
Configuration problem

Symptom

Figure 1 shows the VCTRUNK-shared EVPL service between NE2 and NE3.
Figure 1 Configuration of the VCTRUNK-shared EVPL service
Two pairs of users (D and D', and E and E') share the 300 Mbit/s bandwidth of VCTRUNK1.
  1. Create a flow of the Port type for PORT1 and PORT2 separately.
  2. Create a CoS of the simpletype. Groom the port flow of PORT1 to queue 1 of VCTRUNK1, and groom the port flow of PORT2 to queue 3 of VCTRUNK1.
  3. Enable the traffic shaping function for queue 3 of VCTRUNK1. Set the CIR to 300 Mbit/s.
  4. Enable the traffic shaping function for queue 1 of VCTRUNK1. Use the default shaping parameter values.
Now if the traffic that enters PORT2 reaches a rate of 300 Mbit/s, the service of PORT1 is interrupted. Hence, although certain remaining bandwidth is available, it cannot allocated to queue 1.

Cause Analysis

This problem has the following possible causes.
  1. In this fault case, the priority of queue 3 is higher than the priority of queue 1. As a result, the packets of the higher priority queue 3 occupy the entire 300 Mbit/s bandwidth, and there is no remaining bandwidth for the lower priority queue 1. Consequently, the service between D and D' is interrupted.
  2. The shaping function is enabled for queue 1, but the shaping bandwidth is not set. As the default shaping bandwidth is 0, the service is interrupted.

Procedure

  1. Cause 1: The packets in queue 3 of higher priority occupy all the available bandwidth.
    1. Decrease the bandwidth of the higher priority queue 3.
      1. On the Main Topology, right-click the NE icon and choose NE Explorer from the shortcut menu.
      2. Select the relevant Ethernet board in the Object Tree. Choose Configuration > QoS Management > Port Shaping Management from the Function Tree.
      3. Set the committed information rate (CIR) and burst size (less than 300 Mbit/s).
  2. Cause 2: The shaping function is enabled for queue 1, but the committed bandwidth (CIR) of the shaping function is not set.
    1. Set the shaping bandwidth for queue 1.
      1. On the Main Topology, right-click the NE icon and choose NE Explorer from the shortcut menu.
      2. Select the relevant Ethernet board in the Object Tree. Choose Configuration > QoS Management > Port Shaping Management from the Function Tree.
      3. Select queue 1, and then set the relevant parameters for the queue.

Similar Problems

After a flow is bound with a CAR, the service is interrupted. The possible cause is that, although the CAR is enabled, the CIR and PIR (which are both 0 by default) are not set for the CAR.

Why Automatical configuration backup cannot work on S5700

Posted by at No comments:
Labels: , ,

40G Wavelengths Are Unavailable Due to a DCM Module Connection Problem

40G wavelengths are unavailable due to a DCM module connection problem.

Product

Fault Type

DCM Module

Symptom

10G and 40G wavelengths are transmitted in an OptiX OSN 6800 network. The network topology is shown in the following figure. 40G wavelengths in two directions between station A and station G are unavailable. In addition, the performance of 10G wavelengths is lower than the expected performance although it is stable.

Cause Analysis

The optical power and OSNR after commissioning are normal and the optical fibers are newly routed. In this case, it is impossible that the PMD is excessively high. In addition, the link in the network is long, which results in use of many DCM modules. Therefore, it is possible that the DCM modules at a station are incorrectly connected.

Procedure

  1. Each station between station A and station G uses different DCM modules in two directions and the compensation distance of the two DCM modules differs by more than 40 km. In this case, incorrect connection of DCM modules at any station can make the 40G wavelengths unavailable.
  2. At each station, query the optical power of the optical amplifier boards and calculate the attenuation of the DCM modules. The attenuation of a DCM module increases with the compensation distance of the DCM module.
  3. Check station D. The result shows that station D is abnormal. That is, the attenuation of the DCM module connected to optical amplifier board A03 is lower than that of the DCM module connected to optical amplifier board A05.
  4. Check whether the DCM modules at station D are incorrectly connected. After rectifying the connections, confirm that the 40G wavelengths are available.

Result

The problem is resolved.

Reference Information

None.


TD Alarms Falsely Reported by Some Boards Using Pluggable Optical Modules in WDM Products

Posted by at No comments:
Labels: ,

Services Are Unavailable Due to Inappropriate FEC Configuration on the 40G Regeneration Boards, The System Reports An OTU_LOF Alarm

Services are unavailable because the FEC mode configured on the local 40G regeneration board is inconsistent with that configured on the opposite regeneration board.

Product

OptiX BWS 1600G, OSN6800,OSN8800

Fault Type

Service interruption
Optical Transponder Unit
OTU_LOF

Symptom

OptiX BWS 1600G stations A, B, C, and D using NE software version 5.8.7.12 form an end-to-end chain network. Stations A and D are OTM stations configured with the TMX40S boards. Stations B and C are REG stations configured with the LUR40S boards. Two wavelengths (196.0 GHz and 195.9 GHz) are added and dropped at stations A and D and regenerated at stations B and C.
Not all optical fibers between station A and station B and those between station C and station D are connected but the optical fibers between station B and station C are connected. Therefore, links between station B and station C are commissioned. EVOAs and V40s are configured on the main optical paths along all the links. During commissioning, Laser Status is set to Open for the LUR40S boards. After the optical fibers are connected, the links between station B and station C are remotely commissioned. The commissioning result shows that the bit error rates (BERs) before correction of the two wavelengths received at station B are normal; performance of wavelength 195.9 GHz received at station C is normal and the BER before correction is 1E-10. Performance of wavelength 196.0 GHz received at station C is abnormal and the BER before correction is 1E-2.
The value of FEC Type for the LUR40S board configured with wavelength 196.0 GHz changes between FEC and AFEC on the NMS. The value of FEC Type changes frequently for a certain period, and then is always displayed as FEC. At this time, services are unavailable and the system reports an OTU_LOF alarm.

Cause Analysis

Many factors, such as dispersion adjustment, polarization mode dispersion (PMD), adjustment of receiver thresholds, and optical power fluctuation, can affect the performance of a 40G system. Therefore, the LUR40S board uses the FEC auto-sensing function. That is, if the system performance under the current FEC mode cannot satisfy the system requirements, the LUR40S board automatically changes its FEC mode. However, in certain scenarios the FEC mode cannot be automatically changed.
In the network, wavelengths 195.9 GHz and 196.0 GHz received at station C have the same routes and similar optical power. However, their BERs before correction are different. The cause is that FEC Type is set to FEC for the LUR40S board configured with wavelength 196.0 GHz at station C but is set to AFEC for all other LUR40S boards. The reasons for different FEC modes are described as follows:
  • An LUR40S board switches the FEC mode based on the service access status at the IN optical interface on the WDM side.
  • When two LUR40S boards are connected in a single direction, for example, from the OUT optical interface on the local board to the IN optical interface on the opposite board, the switching process of the FEC mode is as follows (assuming that both boards work in AFEC mode):
    • When no service is received at the IN optical interface on the local board, the board switches the FEC mode at the OUT optical interface from AFEC to FEC.
    • After finding that no service is available, the opposite board switches the FEC mode at the IN optical interface from AFEC to FEC.
    • The local and opposite boards switch their own FEC modes repeatedly even when a service is available at a moment. The local board adapts and regenerates only the upstream service but does not monitor whether the downstream service is normal. Therefore, to commission a service by interconnecting two regeneration boards, you need to disable the FEC auto-sensing function, that is, uniformly set FEC Type to AFEC.

Procedure

  1. In the NE Explorer, select the LUR40S board. Then choose Configuration > WDM Interface from the Function Tree.
  2. Select By Board/Port(Channel).
  3. On the Basic Attributes tab, query and ensure that Service Type is OTU2e (11.1G) for all LUR40S boards.
  4. On the Basic Attributes tab, query and ensure that FEC Type is AFEC for all LUR40S boards.
  5. Then the problem is resolved.

Result

The problem is resolved.

Reference Information

None.


When OptiX OSN 1800 Database Recovery Failures

Posted by at No comments:
Labels: ,

The TN11LOM Board Intermittently Reports the TEMP_OVER Alarm

The TN11LOM board intermittently reports the TEMP_OVER alarm due to the defective threshold crossing mechanism of the ambient temperature.

Product

Fault Type

Optical Transponder Unit
TEMP_OVER

Symptom

Certain TN11LOM boards in the OptiX OSN 6800 V100R003C02B01e equipment intermittently report the TEMP_OVER alarm. The ambient temperature in the telecommunications room, however, is within the normal range.
An equipment environment test conducted by the test engineers shows that the maximum operating temperature of the OptiX OSN 6800 subrack is 47.5°C and the minimum operating temperature of the subrack is 40.3°C when the ambient temperature is 26°C. The three TN11LOM boards in the subrack consecutively report the TEMP_OVER alarm. Query the performance statistics of the equipment. The query result shows that the operating temperatures of the three boards exceed 65°C. About three minutes later, the alarm is cleared. The alarm, however, is reported again two minutes after it is cleared. If you manually set the fan speed of the subrack to a level higher than the current level, the alarm is permanently cleared.

Cause Analysis

The SCC board in the subrack automatically adjusts the fan speed of the subrack according to the operating temperature of the SCC board. When the operating temperature exceeds 47°C, the fan speed is automatically adjusted to the high-speed level.
If a board other than the SCC board in the equipment reports the TEMP_OVER alarm, the fan speed is also automatically adjusted. In this case, the fan speed is automatically adjusted on a stepping basis.
The TN11LOM board detects its operating temperature every 250 ms. When the operating temperature of the board exceeds 65°C, the board reports the TEMP_OVER alarm.
When the operating temperature of the TN11LOM board exceeds 65°C, the board reports the TEMP_OVER alarm though the operating temperature of the SCC board is lower than 47°C. Therefore, the fan speed is automatically stepped up to lower the operating temperature of the equipment. About two minutes later, the operating temperature of the TN11LOM board is lower than 65°C and the TEMP_OVER alarm is cleared. At the same time, the SCC board detects its own operating temperature and finds that the temperature is lower than 47°C. In this case, the SCC board stops stepping up the fan speed and resumes the normal fan speed. Soon afterwards, the operating temperature of the TN11LOM board exceeds 65°C and thus the board reports the TEMP_OVER alarm again. In conclusion, the root cause of the problem that the TN11LOM board intermittently reports the TEMP_OVER alarm lies in the threshold crossing mechanism of the ambient temperature.

Procedure

  1. Set the upper threshold of the operating temperature of the TN11LOM board to 70°C on the T2000. Then, the alarm is cleared. The TEMP_OVER alarm can be cleared in this way but the running life-span of the equipment will be affected in the long term.
    1. In the NE Explorer, select a board and choose Configuration > Environment Monitor Configuration > Environment Monitor Interface from the Function Tree.
    2. Click the Temperature Attributes tab. In the Temperature Upper Threshold (DEG.C) field, set the value to 70.
    3. Click Apply.
  2. Manually adjust the fan speed to boost the heat dissipation efficiency of the equipment.
    1. In the NE Explorer, select an NE and choose Configuration > Fan Attribute from the Function Tree.
    2. Set Fan Speed Mode to Adjustable Speed Mode and set Fan Speed Level to High Speed.
    3. Click Apply.
  3. Do not install multiple TN11LOM boards next to each other, if possible. Install them in the slots in the middle partition of the subrack because the heat dissipation efficiency in the middle partition is higher than that in the other partitions of the subrack.
  4. Pay special attention to the ambient temperature in the telecommunications room. Ensure that the ambient temperature is moderate.

Result

This problem is solved.

Reference Information

Another possible cause for the equipment to report the TEMP_OVER alarm is that the dust filter is dirty and affects heat dissipation. If the alarm is caused by this issue, clean or replace the dust filter as soon as possible. You are advised to clean the dust filter every week and replace it every 6 months.



How to Change the Link Type of an Interface?

Posted by at No comments:
Labels: , ,

Wednesday, June 29, 2016

Failure in Restricting the Bandwidth After Binding the CAR to the Flows

A flow is created after the relevant Ethernet service is created. After the flow is bound with a CAR, it is found that the CAR does not take effect. (On the instrument, the transmit bandwidth is equal to the receive bandwidth.)

Product

Fault Type

  • QoS
  • Ethernet fault

Symptom

As shown in Figure 1, a unidirectional point-to-point EPL service is configured from PORT1 to PORT2 on the same board.
Figure 1 Unidirectional point-to-point EPL service from PORT1 to PORT2
Create the flow at PORT1. Set the flow type to port+VLAN+priority.
Configure the CAR. Set both the CIR and PIR to 10 Mbit/s. Bind the CAR to the flow. Use the SmartBits to transmit packets at a rate higher than 10 Mbit/s. The receive bandwidth of the instrument, however, is found to be equal to the transmit bandwidth of the instrument.

Cause Analysis

This problem has the following possible causes.
  1. The CAR is not enabled. After the CAR is bound to the flow, the CAR is effective for the flow only if the CAR is enabled.
  2. The flow type does not match the service type. In this fault case, a port flow should be configured for the point-to-point EPL service.
  3. Certain boards do not support the flow of the Port type, because the transmitted service packets probably do not match the specified VLAN+priority. Hence, the CAR does not take effect on the flow.

Procedure

  1. Cause 1: The CAR is not enabled.
    1. Enable the CAR.
      1. On the Main Topology, right-click the NE icon and choose NE Explorer from the shortcut menu.
      2. Select the relevant Ethernet board in the Object Tree. Choose Configuration > QoS Management > Flow Management from the Function Tree.
      3. Click the CAR Configuration tab.
      4. Set Enable/Disable to Enable.
  2. Cause 2: The flow type does not match the service type.
    Re-create a flow of the type (that is, port flow) that matches the service type. Then bind the flow with a CAR.
    1. Re-create a flow.
      1. On the Main Topology, right-click the NE icon and choose NE Explorer from the shortcut menu.
      2. Select the relevant Ethernet board in the Object Tree. Choose Configuration > QoS Management > Flow Management from the Function Tree. Then click .
      3. Click the Flow Configuration tab.
      4. Click New. Set the flow attributes in the New Flow dialog box, according to the completed flow planning and the description of flow parameters.
      5. Click OK. The Operation Result dialog box is displayed, indicating that the flow is successfully created.
    2. Bind the flow with a CAR.
      1. On the Main Topology, right-click the NE icon and choose NE Explorer from the shortcut menu.
      2. Select the relevant Ethernet board in the Object Tree. Choose Configuration > QoS Management > Flow Management from the Function Tree. Then click .
      3. Click the Flow Configuration tab.
      4. Select a flow for which you want to configure the binding. In the Bound Shaping, Bound CoS and Bound CAR tabs, select the Shaping ID, CoS ID and CAR ID respectively.
      5. Click Apply. The Operation Result dialog box is displayed, indicating that the binding is successful.
  3. Cause 3: The transmitted service packets do not match the specified VLAN+priority.
    1. Select the relevant board from the NE Explorer. Choose Configuration > Ethernet Service > Ethernet LAN Service from the Function Tree.
    2. Check whether each VLAN priority matches the service packets. If not, set the VLAN priority to the other value.

Posted by at No comments:
Labels: ,

LPT Switching Fails Due to Inconsistency of LPT Bearer Mode

If the LPT bearer modes of the ports at both ends are inconsistent, LPT switching may fail. Hence, ensure that the LPT bearer modes of the ports at both ends are consistent.

Product

Fault Type

  • LPT
  • Fault in the Ethernet

Symptom

In the case of R006 or earlier versions, LPT fails to work normally when the EFS board interconnects with the EMS4 board. After the service at the SDH layer is disconnected, automatic switching can be normally performed at both ends. After the network cable is removed from an Ethernet port, automatic switching at the opposite end fails.

Cause Analysis

In the case of version R006 or earlier than R006, the LPT function of the EFS board supports the MAC bearer mode only whereas the EMS4 board supports the GFP bearer mode only. Hence, the EFS and EMS4 boards fail to interconnect with each other due to different LPT bearer modes after the LPT function is enabled.

Procedure

  1. Modify the LPT bearer modes of the ports at both ends to be the same.

Reference Information

In the case of R006 or earlier versions, do not interconnect the EFGS boards with the EMS4 boards after the LPT function is enabled.


How to Change the Link Type of an Interface?

Posted by at No comments:
Labels: , ,

RPR Network Interruption Due to Incorrect Fiber Connections

Incorrect fiber connections may result in RPR network interruption. In this case, connect the fibers correctly and re-configure the cross-connections.

Product

Fault Type

  • RPR
  • Ethernet fault

Symptom

The fibers are incorrectly connected. In this case, the RPR_NB_INCONSIS alarm is reported, which results in the RPR network interruption. Figure 1 shows incorrect fiber connections.
Figure 1 Incorrect fiber connections

Cause Analysis

The previous fault is caused due to incorrect fiber connections. In this case, ringlet0 receives packets from ringlet1 or ringlet1 receives packets from ringlet0.
As shown in Figure 1, the eastbound adjacent node of S2 is S3 but the westbound adjacent node of S3 is S1 rather than S2. Thus, the RPR_NB_INCONSIS alarm is reported.

Procedure

  1. Query the cross-connection configuration on each board to check whether there are cross-connections that are not completely configured on a board. Configure cross-connections from the Ethernet board to the SDH line board for each NE. See Reference Information.
  2. Check whether the fiber connections on the line board are correct. Connect fibers to make the input and output interfaces of the optical modules match. Figure 2 shows links between nodes. After fibers are connected properly, the alarm is cleared and the fault is rectified.
    Figure 2 Correct fiber connections

Reference Information

The steps of configuring Cross-Connections:
  1. In the Main View, select the desired NE. Right-click the NE and choose NE Explorer from the shortcut menu.
  2. Choose Configuration > SDH Service Configuration from the Function Tree.
  3. Click Create in the lower right of the window. The Create SDH Service dialog box is then displayed.
  4. Set the parameters in the dialog box as follows:
    • Level: VC-4
    • Direction: Bidirectional
    • Source Slot: 13-N2EGR2-1
    • Click . In the Please select the source timeslot dialog box, set the following parameters.
      • Port: 1
      • Higher Order Timeslot: 1,3,5,7,9,11,13,15
    • Sink Slot: 12-N2SL16-1(SDH-1)
    • Sink Timeslot Range: 1-8
    • Activate Immediately: Yes
    • Then, click Apply.
  5. Based on the operations in Step 4, set the parameters in the dialog box as follows:
    • Level: VC-4
    • Direction: Bidirectional
    • Source Slot: 13-N2EGR2-1
    • Click . In the Please select the source timeslot dialog box, set the following parameters.
      • Port: 1
      • Higher Order Timeslot: 2,4,6,8,10,12,14,16
    • Sink Slot: 7-N2SL16-1(SDH-1)
    • Sink Timeslot Range: 1-8
    • Activate Immediately: Yes
    • Then, click Apply.
Posted by at No comments:
Labels: , ,

Monday, June 27, 2016

The Client Equipment Interconnected with the TOM Board Reports the R_LOS Alarm Due to a Problem with the Optical Module on the TOM Board

The client equipment interconnected with the TOM board reports the R_LOS alarm due to a problem with the optical module on the TOM board.

Product

Fault Type

Tributary Unit and Line Unit
R_LOS

Symptom

The SLQ4 board in the client equipment OptiX OSN 3500 interconnected with the TOM board in the OptiX OSN 6800 reports the R_LOS alarm. If you add an optical attenuator to the SLQ4 board, the alarm is cleared. In this case, the R_LOS alarm is reported again if you self-loop a client-side optical interface on the TOM board.

Cause Analysis

There is a problem with the client-side optical module on the TOM board.

Procedure

  1. Replace the client-side optical module on the TOM board to check whether the module is faulty. The R_LOS alarm, however, persists after the module is replaced. This indicates that the module is normal.
  2. Configure the bidirectional services between a client-side optical interface on the TOM board and the client equipment. In this case, the R_LOS alarm is cleared.
  3. Consult the R&D engineers. They explain that the client-side optical module on the TOM board reports the R_LOS alarm instead of the R_LOF alarm upon receipt of all "0"s or all "1"s signals if no service is configured for the module.

Result

To solve the problem, configure services for the client-side optical module on the TOM board.

Reference Information

None.

TD Alarms Falsely Reported by Some Boards Using Pluggable Optical Modules in WDM Products

Posted by at No comments:
Labels: ,

Can I Directly Delete Inner VLAN IDs from QinQ Configuration?

  • If the switch is running V100R005 or an earlier version, one or more inner VLAN IDs in QinQ cannot be directly deleted. You must delete the current selective QinQ configuration, and then reconfigure the inner VLAN IDs that do not need to be deleted.
    For example, the port vlan-stacking vlan 10 to 20 stack-vlan 100 command is configured on the switch(such as S2309TP-EI-AC, S2309TP-EI-DC). To delete inner VLAN 15, perform the following operations:
    1. Run the undo port vlan-stacking vlan 10 to 20 stack-vlan 100 command to delete the current selective QinQ configuration.
    2. Run the port vlan-stacking vlan 10 to 14 stack-vlan 100 and port vlan-stacking vlan 16 to 20 stack-vlan 100 commands to reconfigure the inner VLAN IDs that do not need to be deleted.
  • If the switch is running a version later than V100R005, one or more inner VLAN IDs in QinQ can be directly deleted.

Posted by at No comments:
Labels: , ,

The TDX Board Reports the BUS_ERR Alarm When Cross-Connections Are Configured on the Board Because the Service Type of the Board Is Not Set

The TDX board reports the BUS_ERR alarm when cross-connections are configured on the board because the service type of the board is not set.

Product

Fault Type

Electrical Cross-connection
Tributary Unit and Line Unit
BUS_ERR

Symptom

When the ODU2 cross-connections between the TDX and ND2 boards in the OptiX OSN 6800 on a network are configured, the boards report the BUS_ERR alarm.

Cause Analysis

This problem occurs when the input service type of the board is not set before cross-connections are configured on the board. The problem, however, does not affect the normal operation of the boards on the network.

Procedure

  1. Replace the TDX board to check whether it is faulty. The BUS_ERR alarm, however, persists after the board is replaced.
  2. Reseat the TDX board to check whether it is loose in its slot. The BUS_ERR alarm, however, persists after the board is reseated.
  3. Test the WDM-side signal rates of the TDX and ND2 boards. The test result shows that the WDM-side signal rate of the TDX board is 11.1 Gbit/s while that of the ND2 board is 10.7 Gbit/s. When the cross-connections between the TDX and ND2 boards are configured, the TDX board receives signals at a rate of 11.1 Gbit/s while the rate of the signals sent from the ND2 board is 10.7 Gbit/s. As a result, the boards report the BUS_ERR alarm. If the service type of the TDX board is set to STM-64, the TDX board receives signals at a rate of 11.1 Gbit/s and the problem is solved.

Result

Currently, only the TN12TDX, TN11TQX, TN11ND2, and TN12NS2 boards report the BUS_ERR alarm in the preceding case. These boards support ODU2 cross-connections.
Therefore, the input service type of the TDX board should be set before ODU2 cross-connections are configured on the board.

Reference Information

None.

How to Change the Link Type of an Interface?

Posted by at No comments:
Subscribe to: Posts (Atom)