Showing posts with label OSN7500. Show all posts
Showing posts with label OSN7500. Show all posts

Wednesday, December 28, 2016

What's the MSTP Configuration on display stp

Function

This command is used to query the details of the multiple spanning tree protocol (MSTP). You can analyze and maintain the network topology based on the status and statistical information about MSTP.

Format

display stp [ instance instance-id ] [ port frameid/slotid/portid ]

Parameters

Parameter Description Value
instance instance-id Indicates the spanning tree instance ID. When you need to query the specified spanning tree instance, select this parameter. Numeral type. Range: 0-16. The value 0 indicates common and internal spanning tree (CIST) instance (instance 0), which cannot be deleted.
port frameid/slotid/portid Identifies the shelf/slot/port ID. Enter "/" between the shelf, slot and port IDs. When you need to query the MSTP details of a specified port, use this parameter. Please see Differences Between Shelves.

Modes

Privilege mode, OSN7500, OSN 3500

Level

Common user level

Usage Guidelines

You can analyze and maintain the network topology based on the status and statistical information about MSTP.
  • If you do not specify the spanning tree instance ID and port ID, the system displays the spanning tree information about all instances on all ports, in the sequence of the port ID.
  • If you specify the spanning tree instance ID, the system displays only the spanning tree information about this instance on all ports.
  • If you specify only the port ID, the system displays the information about all spanning tree instances on this port, in the sequence of the port ID.
  • If you specify both the spanning tree instance ID and the port ID, the system displays instance ID and then displays the spanning tree information about the port.

Example

To query the global details of MSTP, do as follows:
huawei#display stp
 The bridge is executing the IEEE Multiple Spanning Tree Protocol
   Bridge Diameter    : 7        Max Hops            : 20
   PathCost standard  : LEGACY   BPDU-Protection     : disabled
   Time Factor        : 3
   TC or TCN received : 0        Time since last TC  : 9 days  2h:27m:33s
   MD5-key            : 13AC06A62E47FD51F95D2BA243CD0346

   ============================== Instance  0 ==================================
   Bridge     Priority  : 32768   MAC Address  : 00e0-fc00-c16b
              Hello Time:  2 sec  Forward Delay: 15 sec  Max Age: 20 sec
   IST Root   Priority  : 32768   MAC Address  : 00e0-fc00-c16b
              Hello Time:  2 sec  Forward Delay: 15 sec  Max Age: 20 sec
   CST Root   Priority  : 32768   MAC Address  : 00e0-fc00-c16b
              Hello Time:  2 sec  Forward Delay: 15 sec  Max Age: 20 sec

   Path cost to IST root bridge is 0
   Path cost to CST root bridge is 0
   -----------------------------------------------------------------------------
   Index  F/ S/ P  Priority  Cost      Admin-State  Role  State      Type
   -----------------------------------------------------------------------------
   1      0/ 3/ 0  128       200000    Enabled      Disa  Down       None
   2      0/ 3/ 1  128       200000    Enabled      Disa  Down       None
   -----------------------------------------------------------------------------
To query the MSTP details of instance 1, do as follows:
huawei#display stp instance 1
 The bridge is executing the IEEE Multiple Spanning Tree Protocol
   Bridge Diameter    : 7        Max Hops            : 20
   PathCost standard  : LEGACY   BPDU-Protection     : disabled
   Time Factor        : 3
   TC or TCN received : 0        Time since last TC  : 9 days  2h:29m: 4s
   MD5-key            : 13AC06A62E47FD51F95D2BA243CD0346

   ============================== Instance  1 ==================================
   Bridge     Priority  : 32768   MAC Address  : 00e0-fc00-c16b
              Hello Time:  2 sec  Forward Delay: 15 sec  Max Age: 20 sec
   IST Root   Priority  : 32768   MAC Address  : 00e0-fc00-c16b
              Hello Time:  2 sec  Forward Delay: 15 sec  Max Age: 20 sec

   Path cost to IST root bridge is 0
To query the MSTP details of port 0/19/0, do as follows:
huawei#display stp port 0/19/0
----[CIST][Port1(Down)]----
 Port Protocol       :enabled
 Port Role           :CIST Disabled Port
 Port Priority       :128
 Port Cost           :Config=auto / Active=200000
 Desg. Bridge/Port   :32768.00e0-fc00-c16b / 128.1
 Port Edged(Admin)   :disabled
 Point-to-point      :Config=auto / Active=false
 Transit Limit       :3 packets/hello-time
 Protection Type     :None
 Port Stp Mode       :Stp
 Port Compliance     :auto
 PortTimes           :Hello 2 s MaxAge 20 s FwDly 15 s Message Age 0 s RemHop 20
 BPDU Sent           :0
     TCN: 0, Config: 0, RST: 0, MST: 0
 BPDU Received       :0
     TCN: 0, Config: 0, RST: 0, MST: 0

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

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 2, 2016

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.

Services Are Unavailable Due to Inappropriate Types of Optical Modules

Appropriate types of optical modules need to be selected to match transmission distances.

Fault Type

Unavailable services

Symptom

The OptiX OSN NEs at both ends of the link are configured with the SL4 boards. The SL4 boards are connected through fibers, but services are unavailable.

Cause Analysis

Possible causes of the fault are as follows:
  • The SL4 boards are faulty.
  • The fibers are faulty.
  • The optical distribution frame is faulty.
  • The optical modules are faulty.
  • The distance between the two NEs exceeds the maximum transmission distance supported by the optical modules.

Procedure

  1. Check the parameters associated with the SL4 boards. No exceptions are found. The boards, however, reported the R_LOS alarm, indicating the loss of signal.
  2. Use the optical time-domain reflectometer (OTDR) to test the fibers. The fibers are normal.
  3. Check the connections between the NEs and the optical distribution frame. The connections are normal.
  4. Check the optical modules on the SL4 boards. The optical modules are normal.
  5. Measure the distance between the two NEs. The distance is 26 km whereas the S-4.1 optical modules used on the SL4 boards support a maximum transmission distance of 15 km. Therefore, the services are unavailable due to inappropriate types of optical modules.
  6. Use the appropriate types of optical modules. Then, the fault is rectified.

Monday, July 25, 2016

The External Clock Source Is Unavailable After a Fiber Cut Because the Clock Configuration Is Incorrect

The priorities of the clock sources are set incorrectly, so the external clock source is unavailable after a fiber cut. After the priorities of the clock sources are re-set, the fault is rectified.

Fault Type

  • Bit errors
  • LTI

Symptom

The EOW board on NE A is connected to two clock sources from third-party equipment, the network clock tracing is normal. After a fiber cut occurs on the ring network, the external clock source becomes unvailable. In addition, NE D reports the LTI alarm, and a large amount of bit errors occur.
Cause Analysis
In normal cases, the working path of the clock tracing is external clock source->NE A->NE B->NE C->NE D->NE F; the protection path is external clock source->NE A->NE F->NE D->NE C->NE B. After a fiber cut occurs on the ring network, the clock source of NE D is lost. After the clock configuration of the network is checked, it is found that System Clock Source Priority Table on NE D is not configured.

Procedure

  1. Query the clock subnet configuration by using the NMS.
    1. In the NE Explorer of NE D, choose Configuration > Clock > Clock Subnet Configuration.
    2. Choose the Clock Quality tab, and Choose the Clock Source Quality. Click Query. The return shows that the system receives the G.811 primary reference clock (PRC) from the 11-SL64 board.
    3. Choose View > Clock View to obtain the clock tracing relationship of NE D. The west clock source (on NE C) next to NE D is unavailable, so NE C should trace its east clock source.
  2. In the NE Explorer of NE D, choose Configuration > Clock > Clock Source Priority. Then, select Priority Table for Phase-Locked Sources of 2nd External Clock Output, and click Create to add 8-SL64 and 11-SL64 as clock sources.
  3. In the Clock View, refresh the clock tracing relationship. Then, the alarm clears.

Communication Anomaly Occurs Between the Equipment and the NMS Due to the Setting of the Firewall

If the equipment and the NM server communicate unidirectionly, disable the firewall or antivirus software to restore the communication.

Product

Fault Type

  • DCN fault

Symptom

During the system commissioning, it is found that the NM server can communicate with the OptiX OSN equipment by using the ping command, but the PC used on the equipment side cannot communicate with the NMS.

Cause Analysis

The firewall or antivirus software is used on the NM server.

Procedure

  1. Replace the NM server with a PC, and use the ping command to test the DCN. The result shows that the communication is normal.
  2. Disable the firewall or antivirus software on the NM server. The equipment side can communicate with the NM server by using the ping command.

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

Friday, July 15, 2016

How to do if Incorrect Mode Setting Causes the Extended ECC Communication Failure

When different networks communicate with each other through the interconnected routers, the extended ECC is not available after the extended ECC mode is set to automatic. When the extended ECC mode is set to the specified mode, the fault is rectified.

Fault Type

ECC fault

Symptom

The two networks are connected to each other through Ethernet cables, but they cannot communicate with each other.

Cause Analysis

The possible causes are as follows:
  • The IP address is configured incorrectly.
  • The extended ECC mode is set incorrectly.

Procedure

  1. Query the IP addresses of the two NEs and the IP addresses of the routers connected to the two NEs.
    • NE A:
      IP address: 129.9.1.1
      Subnet mask: 255.255.255.0
      Gateway: 129.9.1.111
    • Router A:
      IP address: 129.9.1.111
      Subnet mask: 255.255.255.0
    • Router B: IP address:
      129.9.0.111
      Subnet mask: 255.255.255.0
    • NE B:
      IP address: 129.9.0.1
      Subnet mask: 255.255.255.0
      Gateway: 129.9.0.111
    The IP addresses are configured correctly, but the extended ECC is still unavailable.
  2. Query the ECC extended mode. It is found that ECC Extended Mode is set to Auto mode.
  3. Set ECC Extended Mode to Specified mode.
     NOTE:
    Select NE A as the server and NE B as the client. Input the IP addresses and port IDs of NE A and NE B in Set Server and Set Client respectively.
  4. After the preceding operations are complete, the extended ECC communication is restored.

Reference Information

  • Auto mode: In this mode, the extended ECC connection is established automatically. The configuration of the automatic mode is easy, but extra connections are established. Hence, the resource utilization ratio is low. It is recommended that the automatic mode be used only when there are less than nine NEs. In addition, two NEs can automatically establish an extended ECC for communication only after the ECC extended modes of the two NEs are set to Auto mode.
  • Specified mode: In this mode, the extended ECC is established between specified servers and clients. The extended ECC is of high reliability and the bandwidth is effectively used. Generally, the specified mode is adopted to establish the extended ECC connection.

How to Repeated Clock ID Causes the Free-Run of the NE Clock?

The ID of the internal clock source is the same as the ID of the external clock source, which results in the free-fun of the NE clock. When the setting of the internal clock source ID is cancelled, the fault is rectified.

Product

Fault Type

  • Time synchronization
  • S1_SYN_CHANGE
  • LTI

Symptom

The SL64 board is installed in both slot 8 and slot 11 of the OptiX OSN 3500. The OptiX OSN 3500 and the OptiX OSN 7500 are interconnected. The cross-connect board of each device reports the S1_SYN_CHANGE and LTI alarms.
  • The clock configuration of the OptiX OSN 3500 is as follows:
    • The clock source traced by the line board is obtained from another device, and the priority of the external clock source is higher than the priority of the internal clock source.
    • The reversion mode of the high-priority clock source is set to automatic reversion.
    • The clock quality is set to Automatic Extraction.
    • Protection Status is set to Star Extended SSM Protocol.
    • The clock ID of the line board is not set.
    • The ID of the internal clock source is set to 6.
    • All the clock sources are in the normal state.
  • The clock configuration of the Optix OSN 7500 is as follows:
    • The external clock source exists.
    • No clock ID for either the external clock source or the internal clock source is set.
    • The clock synchronization source is provided by the clock source of the line board with a higher priority.

Cause Analysis

The OptiX OSN 3500 and the OptiX OSN 7500 are located on the same network, and the clocks of the entire network are synchronized with the external clock source of the device outside the network. The ID of the external clock source is 6, which conflicts with the ID of the internal clock source of the Optix OSN 3500. In this case, when the OptiX OSN 3500 detects the signals of the external clock source, after checking the ID of the external source, the OptiX OSN 3500 regards the signals as the internal clock signals. Therefore, to prevent the clock tracing loop, the clock of the OptiX OSN 3500 enters the free-run mode.

Procedure

  1. In the T2000 main topology, right-click the NE icon of the OptiX OSN 3500, and then choose NE Explorer.
  2. Choose Configuration > Clock > Clock Subnet Configuration from the Function tree.
  3. Click the Clock Subnet tab.
  4. Set Internal Clock Source.
     NOTE:
    If the device does not have an external clock source, set Internal Clock Source to (None). If the ID of the internal clock source is required to be set, make sure that the ID is different from the clock IDs of other devices.
  5. Click Apply. In the Operation Result dialog box, click Close.

Tuesday, July 12, 2016

Failing to Add IMA Boards into the DPS Protection Group

IMA boards fail to be added into the DPS protection group, hence failing to realize the DPS protection.

Fault Type

Configuration_Problem

Symptom

Boards fail to be added into the DPS protection group.
The configuration of the DPS protection fails to be performed. The boards fail to be added into the DPS protection group.

Cause Analysis

IMA boards that are added into the DPS protection group must be inserted in the paired slots.

Procedure

  1. Make sure that the IMA boards that are configured with DPS protection are set to the paired slots.

Friday, July 8, 2016

Mismatching Between MA Groups and Associated VCTRUNKs, Hence Causing the Binding Failure

IMA groups fail to be bound with associated VCTRUNKs. You need to configure IMA groups to match with associated VCTRUNKs.

Fault Type

Configuration_Problem

Symptom

The principle of binding VCTRUNKs is met, but VCTRUNKS fail to be bound.

Cause Analysis

Mutual check relation exists between IMA groups and associated VCTRUNKs.

Procedure

  1. If IMA groups are symmetrically configured, make sure that the mapping VCTRUNKs are symmetrical.
  2. If VCTRUNKs are nonsymmetrical, make sure that the mapping IMA groups are nonsymmetrical.