The MSTP Configuration of stp region-configuration

Function Description

The multiple spanning tree protocol (MSTP) applies to the redundant network. MSTP is an improvement of STP and RSTP. MSTP prevents the proliferation and infinite cycling of the packets in the loop network. In addition, MSTP provides multiple redundant paths for VLAN data transmission to achieve the load-sharing purpose. The MA5600T/MA5603T/MA5608T supports MSTP, which is compatible with the STP and RSTP. It supports MSTP loop network that helps meet various networking requirements.

Function

The vlan-mapping module command is used to map all VLANs to the spanning tree instances by modulo. When you need to map VLAN to each spanning tree instance rapidly, run this command. After all VLANs map to the matched spanning tree instance by module algorithm, each VLAN belongs to different spanning tress instance based on the user configuration.
The undo vlan-mapping module command is used to remap all VLANs to common and internal spanning (CIST) instance. When you need to restore the mapping relationship, run this command. After all VLANs are remapped to CIST instance, each VLAN is mapped to CIST instance.

Format

vlan-mapping module module
undo vlan-mapping module

Parameters

Parameter	Description	Value
module	Indicates the module value, that is the number of MSTP instances. When you need to specify the mapping relationship between VLAN and spanning tree instance, use this parameter.	Numeral type. Range: 0-16.

Modes

MST area mode, OSN 3500, OSN 7500

Level

Operator level

Usage Guidelines

• Run the config command to enter global config mode, and then run the stp region-configuration command to enter MST area mode.
• By default, all VLANs map CIST instance, that is, instance 0.
• The command is used to map VLAN to each spanning tree instance rapidly. The ID of the mapped instance is (VLAN ID-1)% module+1.
  • (VLAN ID-1)% module is the modular algorithm for (VLAN ID-1). When you calculate the modular value by 16, VLAN 1 maps to MSTI 1, VLAN 2 maps to MSTI 2. ... VLAN 16 maps to MSTI 16 and VLAN 17 maps to MSTI 1. The rest may be reduced by analogy.
  • Running the command can cause the mapping relationship of all VLANs change. In actual application, you can run this command first, and then run the instance vlan command to adjust the mappings slightly as required.
  • The configuration can be used after it is activated.
• Two devices that belong to a same MST region meet the following requirements:
  • The area names are the same.
  • The area levels are the same.
  • The configuration digest are the same. The configuration digest is calculated by VLAN mapping table of all the spanning trees and MD5-KEY through MD5 ciphering algorithm.

Example

To map all VLANs to spanning tree instance, with the modular value of 1, do as follows:

huawei(stp-region-configuration)#vlan-mapping module                            
{ INTERGER<0-16> }:1                                                         
                                                                                
  Command:                                                                      
          vlan-mapping module 1  

To remap all VLANs to CIST instance, do as follows:

huawei(stp-region-configuration)#undo vlan-mapping module  

System Response

• The system does not display any message after the command is executed successfully.

The MSTP Configuration of vlan-mapping module

Function Description

The multiple spanning tree protocol (MSTP) applies to the redundant network. MSTP is an improvement of STP and RSTP. MSTP prevents the proliferation and infinite cycling of the packets in the loop network. In addition, MSTP provides multiple redundant paths for VLAN data transmission to achieve the load-sharing purpose. The MA5680T/MA5683T/MA5608T supports MSTP, which is compatible with the STP and RSTP. It supports MSTP loop network that helps meet various networking

Function

The vlan-mapping module command is used to map all VLANs to the spanning tree instances by modulo. When you need to map VLAN to each spanning tree instance rapidly, run this command. After all VLANs map to the matched spanning tree instance by module algorithm, each VLAN belongs to different spanning tress instance based on the user configuration.
The undo vlan-mapping module command is used to remap all VLANs to common and internal spanning (CIST) instance. When you need to restore the mapping relationship, run this command. After all VLANs are remapped to CIST instance, each VLAN is mapped to CIST instance.

Format

vlan-mapping module module
undo vlan-mapping module

Parameters

Parameter	Description	Value
module	Indicates the module value, that is the number of MSTP instances. When you need to specify the mapping relationship between VLAN and spanning tree instance, use this parameter.	Numeral type. Range: 0-16.

Modes

MST area mode, OSN 3500, OSN 7500

Level

Operator level

Usage Guidelines

• Run the config command to enter global config mode, and then run the stp region-configuration command to enter MST area mode.
• By default, all VLANs map CIST instance, that is, instance 0.
• The command is used to map VLAN to each spanning tree instance rapidly. The ID of the mapped instance is (VLAN ID-1)% module+1.
  • (VLAN ID-1)% module is the modular algorithm for (VLAN ID-1). When you calculate the modular value by 16, VLAN 1 maps to MSTI 1, VLAN 2 maps to MSTI 2. ... VLAN 16 maps to MSTI 16 and VLAN 17 maps to MSTI 1. The rest may be reduced by analogy.
  • Running the command can cause the mapping relationship of all VLANs change. In actual application, you can run this command first, and then run the instance vlan command to adjust the mappings slightly as required.
  • The configuration can be used after it is activated.
• Two devices that belong to a same MST region meet the following requirements:
  • The area names are the same.
  • The area levels are the same.
  • The configuration digest are the same. The configuration digest is calculated by VLAN mapping table of all the spanning trees and MD5-KEY through MD5 ciphering algorithm.

Example

To map all VLANs to spanning tree instance, with the modular value of 1, do as follows:

huawei(stp-region-configuration)#vlan-mapping module                            
{ INTERGER<0-16> }:1                                                         
                                                                                
  Command:                                                                      
          vlan-mapping module 1  

To remap all VLANs to CIST instance, do as follows:

huawei(stp-region-configuration)#undo vlan-mapping module  

System Response

• The system does not display any message after the command is executed successfully.
• For more information about the error message that the system displays against a command entered with incorrect syntax, see the "Syntax Check" in Parameter.

The MSTP Configuration of stp compliance

Function Description

The multiple spanning tree protocol (MSTP) applies to the redundant network. MSTP is an improvement of STP and RSTP. MSTP prevents the proliferation and infinite cycling of the packets in the loop network. In addition, MSTP provides multiple redundant paths for VLAN data transmission to achieve the load-sharing purpose. The MA5600T/MA5603T/MA5608T supports MSTP, which is compatible with the STP and RSTP. It supports MSTP loop network that helps meet various networking requirements.

Function

The stp compliance command is used to configure the protocol used by a port to transmit bridge protocol data unit (BPDU) packets. After this command is executed successfully, the port uses the configured protocol to transmit BPDU packets.
The undo stp compliance command is used to cancel the protocol used by a port to transmit BPDU packets. After this command is executed successfully, the protocol parameter used by the port to transmit BPDU packets is restored to the default value (auto).

Format

stp compliance port frameid/slotid/portid { auto | dot1w }
undo stp compliance port frameid/slotid/portid

Parameters

Parameter	Description	Value
port frameid/slotid/portid	Indicates the shelf ID, slot ID, and port ID. Enter a slash (/) between the shelf, slot, and port IDs.	Please see Differences Between Shelves.
auto	Indicates that a port will auto-negotiate the protocol with the peer port according to the protocol with which the peer port sending BPDUs complies. If the peer port complies with the MSTP protocol when sending BPDUs, the port will also comply with the MSTP protocol. If the peer port complies with the RSTP protocol when sending BPDUs, the port will comply with the RSTP protocol of the 802.1q 2005 version accordingly.	-
dot1w	Indicates that the port complies with the 802.1w protocol when sending BPDUs. If the peer device connected to the port functions as a root bridge device, and the port of the peer device complies with the RSTP protocol when sending BPDUs, use this parameter.	-

Modes

Global config mode, OSN 7500, OSN 3500

Level

Operator level

Usage Guidelines

You can run the display stp command to query the type of the protocol with which the current port sending BPDUs complies.

Example

To set the protocol used by port 0/19/0 to transmit BPDU packets to dot1w, do as follows:

huawei(config)#stp compliance
{ port<K> }:port 
{ frameid/slotid/portid<S><Length 5-18> }:0/19/0
{ auto<K>|do1w<k> }:dot1w

  Command:
          stp compliance port 0/19/0 dot1w

To restore the protocol used by port 0/19/0 to transmit BPDU packets to auto, do as follows:

huawei(config)#undo stp compliance 
{ port<K> }:port 
{ frameid/slotid/portid<S><Length 5-18> }:0/19/0

  Command:
          undo stp compliance port 0/19/0

System Response

• The system does not display any message after the command is executed successfully.

More blog:

How to check the ifindex of an interface on the switch?

When cannot ping the server through S5700HI VLL network.

How to add an ethernet interface on Solaris Operating Syster?

The MSTP Configuration on debugging stp

Function

The debugging stp command is used to enable the debugging switch of the global error or global event of MSTP, or enable the debugging switch of the RX/TX packet and event of the port. When you need to query the details of all ports or the specified port, enable the related debugging switch. After that, the system reports the related details of the ports.
The undo debugging stp command is used to disable the debugging switch of the global error or global event of MSTP, or disable the debugging switch of the RX/TX packet and event of the port. When you do not need to query the details of all ports or the specified port, disable the related debugging switch. After that, the system does not report the related details of the ports.

Format

debugging stp { global-error | global-event | all }
debugging stp [ port frameid/slotid/portid [ instance { all | startinstance [ to endinstance ] } ] ] { packet { send | receive | all } | event }
debugging stp instance startinstance event
debugging stp [ port frameid/slotid/portid ] packet { send | receive | all } number integer
undo debugging stp { global-error | global-event | all }
undo debugging stp [ port frameid/slotid/portid [ instance { all | startinstance [ to endinstance ] } ] ] { packet { send | receive | all } | event }
undo debugging stp instance startinstance event

Parameters

Parameter	Description	Value
global-error	Indicates the debugging switch of the global errors. It includes: packet format error invoke function error	-
global-event	Indicates the debugging switch of the global event. It includes: RX/TX packet port status/role transition state machine transition	-
all	In the command of debugging stp global-event | all, indicates all debugging switches (errors and events).	-
port frameid/slotid/portid	Indicates the subrack ID, slot ID, and port ID. Enter a slash (/) between the subrack, slot, and port IDs. When you need to set the debugging switch of the port, use this parameter.	Please see Differences Between Shelves.
instance	Indicates the keyword of the spanning tree instance.	-
all	In the commend of debugging stp port frameid/slotid/portid instance all, indicates all spanning tree instances.	-
startinstance	Indicates the start instance. The value 0 indicates the common and internal spanning tree (CIST) instance and the other values indicate the multiple spanning tree instance (MSTI).	Numeral type. Range: 0-16.
to endinstance	Indicates the end instance. When you need to set a sequence of spanning tree instances, use this parameter.	Numeral type. Range: 0-16.
packet	Indicates the debugging switch of the BPDU. It includes: RST (Rapid Spanning Tree) BPDU MST (Multiple Spanning Tree) BPDU Config BPDU	-
send	Indicates the debugging switch of the TX BPDU packet.	-
receive	Indicates the debugging switch of the RX BPDU packet.	-
event	Indicates the debugging switch of the event. It includes: RX/TX packet port status/role transition state machine transition	-
all	In the commend of debugging stp packet all, indicates the debugging switches of the RX and TX BPDU packet.	-
number integer	Indicates the number of printed packets. The command will stop automatically after printing all the information of the packets with indicated number.	Numeral type. Range: 1-65535.

Modes

Privilege mode, OSN 7500, OSN 3500

Level

Operator level

Usage Guidelines

• This command must be used with the terminal monitor and terminal debugging commands. The debugging information can be reported to the CLI terminal only when the functions in these two commands are enabled.
• After the debugging switch of the global event of MSTP is enabled, you can query the related information about the RX packets and the state machine of all ports.
• After the debugging switch of the global error of MSTP is enabled, you can query the error information about the port.
• After the debugging switch of the RX/TX packets of the specified MSTP port is enabled, you can query the details of the RX/TX packets of the specified port, debugging by instance is not supported.
• After the event debugging switch of the specified MSTP instance is enabled, you can query the related information about the state machine of the instance, debugging by port is not supported.

Example

To enable the debugging switch of the global event of MSTP, do as follows:

huawei#debugging stp                                                            
{ all<K>|event<K>|global-error<K>|global-event<K>|instance<K>|packet<K>|port<K> 
}:global-event
                                                                                
  Command:                                                                      
          debugging stp global-event                                            

To enable the debugging switch of the RX/TX packets of port 0/19/0, do as follows:

huawei#debugging stp                                                            
{ all<K>|event<K>|global-error<K>|global-event<K>|instance<K>|packet<K>|port<K> 
}:port                                                                          
{ frameid/slotid/portid<S><Length 5-18> }:0/19/0                                              
{ event<K>|instance<K>|packet<K> }:packet                                       
{ all<K>|receive<K>|send<K> }:all                                               
{ <cr>|number<K> }:                                                                                

  Command:                                                                      
          debugging stp port 0/19/0 packet all                                   

To disable the debugging switch of the RX/TX packets of port 0/19/0, do as follows:

huawei#undo debugging stp                                                       
{ all<K>|event<K>|global-error<K>|global-event<K>|instance<K>|packet<K>|port<K> 
}:port                                                                          
{ frameid/slotid/portid<S><Length 5-18> }:0/19/0                                              
{ event<K>|instance<K>|packet<K> }:packet                                       
{ all<K>|receive<K>|send<K> }:all                                               
                                                                                
  Command:                                                                      
          undo debugging stp port 0/19/0 packet all                              

To enable the debugging switch of RX/TX packets of port 0/19/0 , and indicate the number of packets, do as follows:

huawei#debugging stp                                                            
{ all<K>|event<K>|global-error<K>|global-event<K>|instance<K>|packet<K>|port<K> 
}:port                                                                          
{ frameid/slotid/portid<S><Length 5-18> }:0/19/0
{ event<K>|instance<K>|packet<K> }:packet                                     
{ all<K>|receive<K>|send<K> }:all                                             
{ <cr>|number<K> }:number
{ integer<U><1,65535> }:5
                                                                                
  Command:                                                                      
          debugging stp port 0/19/0 packet all number 5                   

System Response

• The system does not display any message after the command is executed successfully.

More blog:

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

How to do when Anomalies Occur After Main Subrack Becomes Extended Subrack?

When Interruption of Existing Services on Some Data Boards of OSN Products

SHDSL Crosstalk Cancellation Group Configuration----shdsl cross-talk-cancellation-group deactivate

shdsl cross-talk-cancellation-group deactivate

Function

This command is used to deactivate a crosstalk cancellation group of the SHDSL line. When you need not use the crosstalk cancellation technology to cancel the crosstalk between lines, run this command. After a crosstalk cancellation group of the SHDSL line is deactivated, the crosstalk cancellation function on the chipset does not take effect any more.

Format

shdsl cross-talk-cancellation-group deactivate group-index

Parameters

Parameter	Description	Value
group-index	Indicates the index of a crosstalk cancellation group of the SHDSL line.	Numeral type. Range: SCU board: 0-63 MCUD/MCUD1: 0-15

Modes

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 you need to deactivate a crosstalk cancellation group, ensure that all the ports in the crosstalk cancellation group must be deactivated.
• After deactivating a crosstalk cancellation group, you can change or delete the crosstalk cancellation group but cannot activate the port in the crosstalk cancellation group independently.

Example

To deactivate a crosstalk cancellation group that contains four ports, do as follows:

huawei(config-if-shl-0/3)#shdsl cross-talk-cancellation-group
{ activate<K>|add<K>|deactivate<K>|delete<K>|modify<K> }:deactivate
{ group-index<U><0,63> }:0

  Command:
          shdsl cross-talk-cancellation-group deactivate 0   

System Response

• The system does not display any message after the command is executed successfully.

MORE BLOG:

What’s the Ethernet features in terms of function of the OptiX OSN 1500 V1R2?

When downgrade failed on S5700-28X-PWR-LI-AC running V200R002C00SPC100

How to authenticate specific users on a interface

An NE Became Unreachable to the NMS After Line Boards Were Cold Reset

Lower-rate multiport line boards preempted DCC resources of higher-rate line boards after line boards were cold reset during an NE upgrade or expansion. As a result, the NE became unreachable to the NMS. The fault was rectified by releasing DCC resources on lower-rate line boards.

Product

OptiX OSN 3500, OSN 2500, OSN 7500

Fault Type

• DCN fault
• DCC_CHAN_LACK

Symptom

Before an NE upgrade or expansion, the NE did not report any alarms, and DCC communication was normal. After an NE was upgraded or expanded, line boards reported the DCC_CHAN_LACK alarms, and the NE became unreachable to the NMS.

Cause Analysis

During an NE upgrade or expansion, line boards were cold reset, and DCC resources were re-allocated. The lower-rate line boards preempted DCC resources of the higher-rate line boards. As a result, the NE became unreachable to the NMS.

Procedure

1. Checked whether there were any bit errors in DCC byte transmission. The transmit end sent DCC bytes, but the receive end did not receive any. Therefore, this issue was not related to bit errors.
2. Went to the site and checked the NE status.
   1. Connected a PC directly to the NE, and logged in to the NE.
   2. Checked the ECC protocol settings. The settings were correct. Therefore, this issue was not related to the ECC protocol settings.
   3. Performed a switchover from the active SCC board to the standby SCC board. The DCC_CHAN_LACK alarms persisted. Therefore, this issue was not related to an SCC board.
   4. Removed the lower-rate line boards. The higher-rate line boards immediately began to transmit data. The DCC_CHAN_LACK alarms cleared, and NEs communicated properly with each other. It was inferred that the lower-rate line boards preempted DCC resources of the higher-rate line boards, blocking the NMS from reaching the NE.
       NOTE:

      • Generally, an SCC board supports multiple DCC working modes, and some DCC working modes provide more DCC resources.
      • In the default DCC working mode for the N1GSCC board, the D1 to D3 bytes function as physical transmission channels and 10 optical ports are DCC-enabled.
      • Generally, a lower-rate line board has multiple optical ports. For example, an SLT1 board has 12 optical ports. After the line boards were cold reset, DCC resources were re-allocated. The lower-rate line boards preempted DCC resources of the higher-rate line boards. The higher-rate line boards failed to obtain DCC resources, blocking the NMS from reaching the NE.
   5. Re-installed the lower-rate line boards.
3. Checked for the DCC_CHAN_LACK alarm on the NMS after the NE was running properly. The DCC_CHAN_LACK alarm persisted, and the NE became unreachable again.
4. Released DCC resources from optical ports on the lower-rate line boards. The optical ports on the higher-rate line boards restored to transmit data. The DCC_CHAN_LACK alarm cleared, and the NE became reachable from the NMS. It was determined that the lower-rate line boards preempted DCC resources of the higher-rate line boards, blocking the NMS from reaching the NE.
    NOTICE:

   Before an NE upgrade or expansion, properly allocate DCC resources. Specifically, release some DCC resources from lower-rate multiport line boards so high-rate line boards can obtain sufficient DCC resources upon cold resetting.

Related Information

None

MORE BLOG:

How to Bootrom password for X7 switch

When you cannot find 10GE port on S7700?

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

Certain Ports on the N1SLQ4 Board Are Unavailable due to Bus Wiring Limitation of the Cross-Connect Board

Certain ports on the N1SLQ4 board are unavailable due to the bus wiring limitation of the cross-connect board. This problem is solved by reinstalling the N1SLQ4 board.

Product

OptiX OSN 3500, OSN 2500, OSN 7500

Fault Type

Cross-connect unit

Symptom

The OptiX OSN 3500 is configured with the N1SXCSA board. Two N1SLQ4 boards are installed in slots 4 and 15, but only the former two optical interfaces of the boards are available.

Cause Analysis

When planning the slots of boards, you need to consider the access capacity of slots, the bus wiring of the cross-connect board, and the bus rate of the board.

1. The OptiX OSN 3500 is configured with the N1SXCSA board. The access capacities of slots 5 and 14 are 5 Gbit/s. The total rate of the ports on the N1SLQ4 board is 2.5 Gbit/s. Therefore, the problem is not caused by access capacity limitation.
2. The N1SXCSA board can adapt to 622 Mbit/s buses and 2.5 Gbit/s buses.
3. The bus rate of the N1SLQ4 board is 622 Mbit/s, so four 622 Mbit/s buses are required to support the four optical interfaces on the board. However, slots 4 and 15 provide only two buses respectively. Therefore, only the former two optical interfaces on the boards are available.

Procedure

1. Reinstall the N1SLQ4 boards into slots 5 and 14. Slots 5, 6, 13, and 14 provide four buses. Then, all optical interfaces on the boards are available.

Related Information

On the OptiX OSN equipment, two types of backplane buses are available, namely, 622 Mbit/s and 2.5 Gbit/s. The bus specifications of the OptiX OSN equipment are as follows:

• The OptiX OSN 1500 supports 622 Mbit/s buses only.
• The OptiX OSN 2500 supports 622 Mbit/s buses only.
• When configured with the GXCSA, EXCSA, or UXCSA/UXCSB, the OptiX OSN 3500 supports 622 Mbit/s buses only. When configured with the SXCSA/SXCSB, IXCSA/IXCSB, or FXCSA, the OptiX OSN 3500 can adapt to 622 Mbit/s buses and 2.5 Gbit/s buses.
• The OptiX OSN 7500 can adapt to 622 Mbit/s buses and 2.5 Gbit/s buses.

MORE BLOG:

How to Replace the Satellite Card of the SRCU Board in the BITSV3

What’s the Failure of I-Type PDU Backplane on MA5600T due to Overcurrent

How to do when Occasional MA5616 Database Clearing?

LASER_MODE_ERR Caused by the Incorrect Optical Module on the SL16 Board

The LASER_MODE_ERR alarm occurs because an incorrect optical module is used on the SL16 board. This problem is solved by replacing the incorrect optical module with a correct one.

Product

OptiX OSN 3500, OSN 2500, OSN 7500

Fault Type

LASER_MODE_ERR

Symptom

The SL16 board on the OptiX OSN 3500 reports the LASER_MODE_ERR alarm. The SL16 board is interconnected with a 2.5 Gbit/s optical interface and does not report any abnormal alarm about optical signals.

Cause Analysis

Query the board manufacturing information.

shows the query result.

The query result indicates that the optical module on the SL16 board is MXPD-243S and has a rate of 622 Mbit/s. In fact, the optical module is a GE module.

The board reports the LASER_MODE_ERR alarm because the rate of the optical module (1.25 Gbit/s) is different from the rate of the board (2.5 Gbit/s). When you query the SDH signal rate of the optical module, the maximum rate of the optical module is the maximum rate lower than 1.25 Gbit/s. Therefore, the query result indicates that the maximum rate of the optical module is 622 Mbit/s.

Procedure

1. Replace the original optical module with a 2.5 Gbit/s optical module. The SL16 board receives and transmits STM-16 signals, so the 2.5 Gbit/s optical module matches the board. Then, the LASER_MODE_ERR alarm clears.

Related Information

None.

MORE BLOG:

How to authenticate specific users on a interface

How to delete interface configuration using one command?

How to Replace the Satellite Card of the SRCU Board in the BITSV3

Failure to Log In To the OptiX OSN 2500 REG Through ECC due to Incorrect Board Configuration

The ECC communication of the OptiX OSN 2500 REG is unavailable due to incorrect board configuration. This problem is solved by installing the relevant boards in paired slots.

Product

OptiX OSN 2500 REG, OSN 3500, OSN 7500

Fault Type

ECC fault

Symptom

Two SL16 boards are installed in slots 7 and 8 on the OptiX OSN 2500 REG. After the boards are connected to the upstream NE and downstream NE through fibers, the ECC communication of the OptiX OSN 2500 REG is unavailable.

Cause Analysis

The possible causes are as follows:

• Fibers are misconnected.
• The board software is faulty or the NE software is faulty.
• Board configuration is incorrect.

Procedure

1. Check the fiber connections and confirm that the fiber connections are correct.
2. Check the alarms on the NE and find no abnormal alarms. The board software and the NE software are normal.
3. The OptiX OSN 2500 REG has special requirements for fiber connections. The ECC communication in a certain direction must be achieved through the IN port on one optical interface board and the OUT port on another optical interface. After the ECC messages are received by an optical interface of a line board on the OptiX OSN equipment, the ECC messages are sent to the SCC board and the board in the paired slot. Therefore, only the line boards in paired slots can receive the ECC messages in one direction. Slots 8 and 11, slots 7 and 12 are paired slots. The ECC communication is unavailable on the OptiX OSN 2500 REG because the SL16 boards are not installed in paired slots.
4. Reinstall the SL16 board in slot 8 into slot 12. Then, the ECC communication of the OptiX OSN 2500 REG is available.

Related Information

On the OptiX OSN 2500 REG, one pair of IN and OUT optical interfaces must be connected to the west and the east respectively. This connection method is similar to the REG board on the WDM equipment. Fibers can be misconnected easily on site.

MORE BLOG:

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

How to do when Anomalies Occur After Main Subrack Becomes Extended Subrack?

When Interruption of Existing Services on Some Data Boards of OSN Products

Services on SNCP Rings Become Unavailable due to Fiber Misconnections

Services on two SNCP rings become unavailable due to fiber misconnections. This problem is solved by reconnecting the fibers.

Product

OptiX OSN 3500, OSN 2500, OSN 7500

Fault Type

SNCP fault

Symptom

NE C (the OptiX OSN 3500) forms two 155 Mbit/s SNCP rings with two groups of STM-1 optical interfaces. Ring 1 connects NE A (the OptiX Metro 1000) and Ring 2 connects NE B (the OptiX Metro 1000). NE A and NE B send 2 Mbit/s services respectively to port 1 and port 2 on NE D. Figure 1 shows the network diagram.

Figure 1 Correct SNCP network diagram

After the fibers on Ring 1 and Ring 2 are cut over, NE C does not report any alarm or performance event. The services on Ring 1 and Ring 2, however, are interrupted.

Cause Analysis

Possible causes of the problem are as follows:

• The services are incorrectly configured.
• The loopback of services is not released.
• Fibers are misconnected.

Procedure

1. Check the service configuration and confirm that the service configuration is correct. In addition, the cutover does not change the services.
2. Perform an outloop respectively at the tributary ports on NE A, NE B, and NE D. The outloops are normal, indicating that the NEs are connected properly.
3. Perform an inloop for the 2 Mbit/s services on NE A and test the signals at Port 1 on NE D. The test reports the OOF alarm.
4. Deactivate the services that NE D receives from NE B. As a result, the APS switching occurs on NE A. In addition, the services on NE A recover. It can be inferred that fibers are misconnected.
5. Check the fiber connections between NE A and NE C, between NE B and NE C by modifying the J0 byte. It is found that one pair of fibers on Ring 1 and one pair of fibers on Ring 2 are not connected as shown on the NMS. Figure 2 shows the incorrect SNCP network diagram.
   Figure 2 Incorrect SNCP network diagram
   
6. Reconnect the fibers according to the fiber connections before the cutover. Then, the fault is rectified.

Related Information

If the transport equipment does not report any alarm or performance event, the network is not necessarily normal on the transport side.

Therefore, after a cutover that involves fibers connections on the transport side, you need to carefully check the fiber connections and ensure that the fiber connections are the same as before the cutover.

Try to use meters for troubleshooting and judge based on the testing results of meters.

MORE BLOG:

Description on the flow control of the NG SDH EFT data board

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

Access Capacity of Slots of the OptiX OSN 1500 V1R2

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

Function

This command is used to modify an SHDSL alarm profile. When the alarm thresholds of the alarm profile can not meet the requirement, you can adjust the parameter settings in an SHDSL alarm profile, run this command. After that, the new alarm thresholds take effect immediately.

Format

shdsl alarm-profile modify profile-index

Parameters

Parameter	Description	Value
profile-index	Indicates the SHDSL alarm profile number. It identifies the SHDSL alarm profile to be modified. The system has one default SHDSL alarm profile (profile 1). If the switch for reporting the terminal power-off alarm is disabled, all parameters in the default profile are 0, which indicates that no alarm is reported.	Numeral type. Range: 1-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.
• The values to be configured in an SHDSL alarm profile is the thresholds within any 15-minute period. When a statistic reaches the threshold, the system informs the device of the event, and sends alarms to the NMS.
• Threshold 0 indicates that the system does not collect performances and does not report the alarm.

Example

To modify SHDSL alarm profile 2, do as follows:

huawei(config)#shdsl alarm-profile modify
{ profile-index<U><1,99> }:2                                                   
                                                                                
  Command:                                                                      
          shdsl alarm-profile modify 2 
  Start modifying profile 2. New setting will take effect automatically after
the modification succeed
  During inputting,press 'Q' to quit,then settings at this time will be ignored
> Do you want to restore data to default?(y/n)[n]:
<STU-C>
>  Loop attenuation threshold (0~127 dB)[0]:127
>  SNR margin threshold (0~15 dB)[0]:10
>  ES threshold (0~900 s)[0]:900
>  SES threshold (0~900 s)[0]:900
>  CRC anomaly threshold (0~58981500)[0]:50000000
>  LOSWS threshold (0~900 s)[0]:900
>  UAS threshold (0~900 s)[0]:900
  <STU-R>
>  Loop attenuation threshold (0~127 dB)[0]:127
>  SNR margin threshold (0~15 dB)[0]:10
>  ES threshold (0~900 s)[0]:900
>  SES threshold (0~900 s)[0]:900
>  CRC anomaly threshold (0~58981500)[0]:30000000
>  LOSWS threshold (0~900 s)[0]:900
>  UAS threshold (0~900 s)[0]:900
> The dying gasp alarm switch(1-enable, 2-disable)[1]:2
> The active fail alarm switch(1-enable, 2-disable) [1]:
  Modify profile 2 successfully, and new setting is taking effect now
  The flow for the profile to take effect is complete

System Response

• The system displays the message "Modify profile x successfully" after you modify the SHDSL alarm profile successfully. "x" is the number of the modified profile.
• The following table describes the parameters in response to the shdsl alarm-profile modify command.

  Parameter	Description
  Do you want to restore data to default?	If you select "y" in this option, the system uses the parameters in the default profile 1 to modify the alarm-profile. The configuration of the alarm profile ends. If you select "n", continue the configuration of the alarm profile.
  Loop attenuation threshold (0~127 db)[0]	Indicates the loop attenuation threshold. The system collects the related performance data generated within any 15-minute period. If the loop attenuation exceeds the threshold, the system will report an alarm. Range: 0-127 dB. 0 dB indicates that the alarm threshold is disabled.
  SNR margin threshold (0~15 db)[0]	Indicates the SNR margin threshold. The system collects SNR related performance data generated within any 15-minute period. If the SNR margin exceeds the threshold, the system will report an alarm. Range: 0-15 dB. 0 dB indicates that the alarm threshold is disabled.
  ES threshold (0~900 s)[0]	Indicates the ES threshold. The system collects ES related performance data generated within any 15-minute period. If the accumulated ES exceeds the threshold, the system will report an alarm. Range: 0-900s. 0s indicates that the alarm threshold is disabled.
  SES threshold (0~900 s)[0]	Indicates the SES threshold. The system collects SES related performance data generated within any 15-minute period. If the accumulated SES exceeds the threshold, the system will report an alarm. Range: 0s-900s. 0s indicates that the alarm threshold is disabled.
  CRC anomaly threshold (0~58981500)[0]	Indicates the CRC abnormal threshold. The system collects CRC related performance data generated within any 15-minute period. If the accumulated CRC exceeds the threshold, the system will report an alarm. Range: 0-58981500. 0 indicates that the alarm threshold is disabled.
  LOSWS threshold (0~900 s)[0]	Indicates the LOSWS threshold. The system collects LOSWS related performance data generated within any 15-minute period. If the accumulated LOSWS exceeds the threshold, the system will report an alarm. Range: 0-900s. 0s indicates that the alarm threshold is disabled.
  UAS threshold (0~900 s)[0]	Indicates the UAS threshold. The system collects UAS related performance data generated within any 15-minute period. If the accumulated UAS exceeds the threshold, the system will report an alarm. Range: 0-900s. 0s indicates that the alarm threshold is disabled.
  The dying gasp alarm switch(1-enable, 2-disable)[1]	Indicates the switch for reporting the terminal power-off alarm.
  The active fail alarm switch(1-enable, 2-disable)[1]	Indicates the switch for reporting the line activation failure alarm.
  STU-C	Indicates the central office end of the SHDSL transceiver unit.
  STU-R	Indicates the remote end of the SHDSL transceiver unit.

• For more information about the error message that the system displays against a command entered with incorrect syntax.

MORE BLOG:

Prewarning for ARP Entry Aging Failures on MxU

When Users on Base Stations of Different Vendors Attempt to Get Online Through an ATN Device.

Warning of an ARP Entry Dually-Transmitting Failure