Monthly Archives: June 2016

Why Automatical configuration backup cannot work on S5700

Issue Description

Customer configuration automatical configuration backup function on S5700 and found

it did not work. Check the logs on S5700 and get below alarm.
Sep 25 2014 18:18:51-05:13 S5700-1 %%01CFM/4/B2S_BACKUP_FAILED(l)[0]:Failed

to transfer the configuration file to server X.X.X.X through FTP when automatically backing

up the configuration

Alarm Information

Sep 25 2014 18:18:51-05:13 S5700-1 %%01CFM/4/B2S_BACKUP_FAILED(l)[0]:Failed to

transfer the configuration file to server X.X.X.X through FTP when automatically backing up

the configuration

Handling Process

1. Ping the FTP server IP and make sure the network is fine.
2. Check the configuration and made a local test. Also failed and get same alarm.
3. Check the product documentation and find the path should be relative save path.
path folder :Specifies the relative save path on the server
4. Change the path folder and test it again. It works fine.

Solution

set save-configuration backup-to-server server server-ip transport-type { ftp | sftp } user

user-name password password [ path folder ]

The Path parameter must be relative save path on the server. Or the function cannot

work correctly.

Suggestions

When configuring some function, we need to refer to the product manumal to make sure

the commands is configured correctly.

TwitterLinkedInGoogle+FacebookPinterestTumblrStumbleUponRedditShare

How to Change the Link Type of an Interface?

Issue Description

How Do I Change the Link Type of an Interface?

Solution

Four link types are defined: access, trunk, hybrid, and dot1q-tunnel. The following

provides the methods to set different link types.

1.  Access

[Quidway-GigabitEthernet1/0/1] port link-type access
[Quidway-GigabitEthernet1/0/1] port default vlan 10

The preceding configuration changes the link type of the interface to access.

An access interface processes packets as follows:

When receiving an untagged packet, the interface accepts the packet and tags

it with the default VLAN ID.

When receiving a tagged packet:

If the VLAN ID of the packet is the same as the default VLAN ID of the interface,

the interface accepts the packet.
If the VLAN ID of the packet is different from the default VLAN ID of the interface,

the interface drops the packet.

Before sending a packet, the interface removes the VLAN tag from the packet.

2.  Trunk

[Quidway-GigabitEthernet1/0/1] port link-type trunk
[Quidway-GigabitEthernet1/0/1] port trunk pvid vlan 20
[Quidway-GigabitEthernet1/0/1] port trunk allow-pass vlan 2 10 20

The preceding configuration changes the link type of the interface to trunk.

A trunk interface processes packets as follows:

  • When receiving an untagged packet:

The interface tags the packet with the default VLAN ID. If the default

VLAN ID is in the list of allowed VLAN IDs, the interface accepts the packet.
The interface tags the packet with the default VLAN ID. If the default

VLAN ID is not in the list of allowed VLAN IDs, the interface drops the packet.

  • When receiving a tagged packet:

If the VLAN ID of the packet is in the list of allowed VLAN IDs, the interface

accepts the packet.
If the VLAN ID of the packet is not in the list of allowed VLAN IDs, the interface

drops the packet.

  • When sending a packet:

If the VLAN ID of the packet is the same as the default VLAN and is in the list of

allowed VLAN IDs, the interface removes the tag from the packet and sends the packet.
If the VLAN ID of the packet is different from the default VLAN and is in the list of

allowed VLAN IDs, the interface retains the tag and sends the packet.

3.  Hybrid

[Quidway-GigabitEthernet1/0/1] port link-type hybrid
[Quidway-GigabitEthernet1/0/1] port hybrid pvid vlan 10
[Quidway-GigabitEthernet1/0/1] port hybrid untagged vlan 2 10
[Quidway-GigabitEthernet1/0/1] port hybrid tagged vlan 20

The preceding configuration changes the link type of the interface to hybrid.

A hybrid interface processes packets as follows:

  • When receiving a tagged packet:

The interface tags the packet with the default VLAN ID. If the default VLAN ID is

in the list of allowed VLAN IDs, the interface accepts the packet.
The interface tags the packet with the default VLAN ID. If the default VLAN ID is

not in the list of allowed VLAN IDs, the interface drops the packet.

  • When receiving a tagged packet:

If the VLAN ID of the packet is in the list of allowed VLAN IDs, the interface accepts

the packet.
If the VLAN ID of the packet is not in the list of allowed VLAN IDs, the interface drops

the packet.

  • When sending a packet:

If the VLAN ID of the packet is in the list of allowed VLAN IDs, the interface sends the packet.

You can run the port hybrid untagged vlan command to configure the interface to remove tags

of packets or run the port hybrid tagged vlan command to configure the interface to send tagged packets.

4.  Dot1q-tunnel

[Quidway-GigabitEthernet1/0/1] port link-type dot1q-tunnel
[Quidway-GigabitEthernet1/0/1] port default vlan 20

The preceding configuration changes the link type of the interface to dot1q-tunnel. A dot1q-tunnel

interface adds a VLAN tag to packets before forwarding them, regardless of the original VLAN IDs

of the packets. Before sending a packet, a dot1q-tunnel interface removes the tag with the default

VLAN ID from the packet.

10G Card Issue in Quidway S5300

Issue Description

We have a working Huawei LS-S5328C-EI-24S switch with serial no. 210235162110A8003779

and was originally ordered via Quotation no. 000000036552201006180002 in 2010.

Recently we installed a LS5D00E4XY00 card (4-port 10GE card) with serial no.

020RYTW0D6000672 and originally ordered via Quotation no. 000000754509201305230001

in above mentioned switch in offline mode. However after switch power-up we are unable to get

the 10GE card detected by switch.

Alarm Information

No

Handling Process

You just can upgrade the software version and install the rear card

Root Cause

This Card LS5D00E4XY00
It is 4-port 10GE SFP+ optical interface card (consisting of an LS5D00E4XY01 4-port 10GE front

card and an ES5D00ETPB00 extended channel rear card) So The LS5D00E4XY01 front card must

work with the ES5D00ETPB00 rear card, so The two cards are sold together.
LS5D00E4XY00 is the name of the combination of the two cards.

Also kindly be notices that your S5300 software version is very old, You need to upgrade this

software version because of This card is supported in V100R005 and later versions
Thank you very much for cooperation

Suggestions

No

 

In S5700 when configuring voice vlan there is an error says “no enough resources”

Issue Description

In S5700 when configuring voice vlan there is an error said  the device does have

enough resources ,causing that the reset of

25 ports cannot apply the voice-vlan commands, here is the information :

 

[S5700-GigabitEthernet0/0/22]voice-vlan 302 enable include-untagged

[S5700-GigabitEthernet0/0/22]interface GigabitEthernet0/0 /23

[S5700 -GigabitEthernet0/0/23]undo  voice-vlan 302 enable

[S5700- GigabitEthernet0/0/23]voice-vlan 302 enable include-untagged

Error: This command failed because of no enough resources, please undo it.

From 0/0/1 to 0/0/22 has the same configuration ,the voice-vlan is enabled among

these ports without problem ,but when enable the voice vlan in 0/0/23 ,we can see that

An error popped out  “Error: This command failed because of no enough resources, please undo it.”

Solution

According to the configuration in the S5700, there are 46 OUI configured

 

voice-vlan mac-address 8483-7100-0000 mask ffff-ff00-0000 description avaya

…

voice-vlan mac-address 0015-6500-0000 mask ffff-ff00-0000 description yealink

voice-vlan mac-address 8cb6-4f00-0000 mask ffff-ff00-0000 description cisco

voice-vlan mac-address e468-a300-0000 mask ffff-ff00-0000 description huawei

…(total 46 items)

 

If each port configured the  “voice-vlan 302 enable include-untagged” , it will take up 46 ACL ,and the

total vlan ACL resources for this switch are 1024 ,

 

So only the front 22 port can configure this command without any error ,because 22*46=1012 ,if continue

the same in port 23 , It is not enough  since the rest

 

resources are  only 12 , that is why the device show an error ; the solution is to aggregate the OUI or select

the OUI that is only match the vendor’s IPPHONE

 

which are connected to Switch only ,because in customer site ,it is impossible to have more than 40 vendors’ IPPHONE.

When OptiX OSN 1800 Database Recovery Failures

 

Keywords: OptiX OSN 1800, WDM product family,Transport network product line

Summary: Intelligent fibers are enabled or disabled at an optical port on the OptiX

OSN 1800 V100R001C01SPC100 (5.67.01.19) and the NE is upgraded to V100R002C00

SPC100 (5.67.02.13) or a later version. If intelligent fibers are reconfigured at the same

optical port and the SCC board is reset or backup databases are restored to the NE, the

SCC board cannot start up.

 

[Problem Description]

Trigger conditions:

Intelligent fibers are enabled or disabled at an optical port on the OptiX OSN 1800

V100R001C01SPC100 (5.67.01.19) and the NE is upgraded to V100R002C00 SPC100

(5.67.02.13) or a later version. If intelligent fibers are reconfigured at the same optical

port and the SCC board is reset or backup databases are restored to the NE, the SCC

board cannot start up.

For example, a user enables or disables intelligent fibers at an optical port on the OptiX

OSN 1800 V100R001C01SPC100 (5.67.01.19) and upgrades the NE to V100R002C00

SPC100 (5.67.02.13). Then, the user reconfigure intelligent fibers at the same optical

port. If the user resets the SCC board, the board cannot be started up.

Symptom:

The NE becomes unreachable from the NMS.

Identification method:

Check whether intelligent fibers are configured at an optical port of the OptiX OSN 1800

V100R001C01SPC100 (5.67.01.19), the NE is upgraded to V100R002C00 SPC100

(5.67.02.13) or a later version, intelligent fibers are reconfigured at the same port, and its

SCC board is reset, or backup databases are restored, which cause that the NE becomes

unreachable from the NMS.

 

[Root Cause]

When an OptiX OSN 1800 is upgraded from V100R001C01SPC100 (5.67.01.19) to

V100R002C00 SPC100 (5.67.02.13) or a later version, the SCC board cannot start up

due to intelligent fibers- related command changes and database index recreation

failure after the upgrade adaptation is complete.

 

[Impact and Risk]

Affected scope: in and out of China

Impact: The NE becomes unreachable from the NMS.

 

[Measures and Solutions]

Recovery measures:

Measure 1: Clear databases on the SCC board and reconfigure the services in the NE.

Measure 2: Send the backup databases before the fault occurs back to Huawei R&D

Department for restoration. Then, use the NMS to deliver restored data to the NE.

Workarounds:

Workaround 1: For the OptiX OSN 1800 V100R001C01SPC100 (5.67.01.19) with

intelligent fiber configurations, perform a warm reset on its SCC board after it is

upgraded to V100R002C00 SPC100 (5.67.02.13).

Workaround 2: Check OptiX OSN 1800 equipment on the live network using Smartkit

tools and rectify equipment with latent risks.

Preventive measures:

For the OptiX OSN 1800 V100R001C01SPC100 (5.67.01.19) with intelligent fiber

configurations and upgraded to V100R002C00 SPC100 (5.67.02.13) or a later version,

workaround 1 is recommended.

Database recovery failures are to be rectified in the OptiX OSN 1800 patch version.

You can directly upgrade the OptiX OSN 1800 V100R001C01SPC100 (5.67.01.19)

to a patch version.

Material handling after replacement:

Not involved.

 

[Rectification Scope and Time Requirements]

Not involved.

 

How to Use the Ethernet Test Frames on the OptiX OSN 6800?

This section describes how to use the Ethernet test frames on the OptiX OSN 6800.

Product

OptiX OSN 6800

OptiX OSN 3800

Fault Type

Others

Symptom

None.

Cause Analysis

Using Ethernet test frames is a major method of determining whether the service configuration

on a data board is correct. Certain boards intended for the OptiX OSN 6800 support this feature.

The following section takes the LOG and TDG boards as examples to describe Ethernet test frames.

Whether electrical cross-connections need to be configured when the LOG board is used to test

Ethernet services?Whether electrical cross-connections are configured does not affect the Ethernet

service test on the LOG board. The LOG board can receive response test frames under the condition

that optical path between the local and opposite LOG boards is available.

If the local and opposite TDG boards cross-connect services to the local and opposite LOG boards

respectively, can the local TDG board receive response test frames?

Electrical cross-connections are configured from the TDG board to the WDM side on the LOG board.

The local TDG board cannot receive response test frames because the local LOG board also supports

test frames. Even an inloop is performed at the optical interfaces on the WDM side of the local LOG

board, the local TDG board cannot receive the test frames sent from the local TDG board.

To enable that a TDG board receives test frames, cross-connect the services on the local TDG board

to the local NS2 board, and then the opposite NS2 board cross-connects the services to the opposite

TDG board. That is, electrical cross-connections must be configured when a TDG board tests the

Ethernet services.

Procedure

  1. None.

Result

The problem is resolved.

Reference Information

None.

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

When the OptiX OSN 1500 is connected to the 155 Mbit/s optical port of the router of

company C, the LP_RDI alarm is generated in the 2 Mbit/s service. The relevant analysis

shows that the higher order path overheads of the line board are in the pass-through state,

which results in the lower order service interruption. Hence, the overhead mode must be

correctly set before a higher order service is changed to a lower order service.

Product

OptiX OSN 1500

Fault Type

  • Equipment Interconnection Failure
  • Service interruption
  • LP-RDI

Symptom

During network expansion, the SLQ1 board of the OptiX OSN 1500 is connected directly

to the optical card of the router of company C. The network is configured with 1+1 linear

multiplex section protection (MSP). One end of the MSP line is the 2 Mbit/s service and

the other end is the 155 Mbit/s optical service. The LP_RDI alarm is reported in the

2 Mbit/s service.

Cause Analysis

Check the optical transmission paths, timeslot interconnection, router hardware, and

overhead modes of the SDH boards.

Procedure

 

1. After you confirm that the physical connections are normal, the receive optical power

of both the SLQ1 board and the optical interface of company C is normal, no optical power
alarm is generated on the receive side, but the link status of the router of company C is down.
2. Query the alarm. It is found that no abnormal alarms are generated on the SLQ1 board,
but the LP_RDI alarm is reported in the 2 Mbit/s service on the other end.
Perform inloop at the optical port that is interconnected with the SLQ1 board. It is found that
the LP_RDI alarm in the 2 Mbit/s service is cleared. It indicates that the optical transmission
paths are normal.
3. Perform outloop at the optical port that is interconnected to the SLQ1 board. It is found that
the link status of the router of company C is up. In this case, it is suspected that the fault exists
in the timeslot interconnection.
4. Check the relevant information. It is found that the first VC-12s of the VC-4s on the SLQ1 board
carry the services and that the first VC-12s of the VC-4s on the router of company C carry the services.
Add a 2 Mbit/s service in the twenty-second VC-12 on the SLQ1 board that corresponds to the second
VC-12 on the router of company C. It is found that the LP_RDI persists in the 2 Mbit/s service at the
opposite end. In this case, it is suspected that the local end fails to receive the optical signals.
Reset the router and then restart the router. It is found that the fault persists.
5. Check the SDH service configuration. The original service of the optical port that is interconnected
to the SLQ1 board at the local end is a VC-4 service. Delete this VC-4 service and add a VC-12 service.
In this case, the overhead mode should be Termination. Query the overhead mode. It is found that
the actual overhead mode is Pass-Through. Then, change the overhead mode to Termination.
It is found that the LP_RDI alarm is cleared and that the services are normal.

Reference Information

When you configure a lower order service, the higher order path overheads must be set to the

Terminal mode. Otherwise, the services may be interrupted.

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

 

Keywords: WDM products, OptiX OSN 8800

Summary:

If no intra-board cross-connection from the WDM side to the client side is configured for

boards that support intra-board cross-connections, these boards may falsely report TD

alarms when their optical port lasers are turned on.

[Problem Description]

Trigger conditions:

The problem occurs on a board when the following conditions are present:

The board is listed in the table above. No intra-board cross-connection shown in Figure 1

is configured on the board. Specifically, no unidirectional cross-connection from the WDM

side to the client side is configured on the board.

Figure 1 Intra-board cross-connection

 

WDM side

WDM side

Pluggable optical modules are used on the board and the optical port lasers are turned on.

Symptom:

TD alarms are reported.

Identification method:

The problem occurs if the trigger conditions and symptom are satisfied.

[Root Cause]

When no intra-board cross-connection shown in Figure 1 is configured on the board, the module

bias current increases. In addition, the laser transmit efficiency decreases when the ambient temperature

increases. To maintain stable module power, the bias current further increases. When the bias current

increases to a value greater than the alarm threshold, TD alarms are reported. The laser transmit efficiency

varies according to modules. Therefore, not all modules have this problem.

[Impact and Risk]

The board falsely reports TD alarms. Consequently, operators may consider that the optical modules are faulty.

[Measures and Solutions]

Recovery measures:

Take either of the following measures:

Turn off the lasers after confirming that no service is deployed.

Configure intra-board cross-connections for the related optical ports.

Workarounds:

Turn on the lasers after configuring intra-board cross-connections.

Preventive measures:

Update the related product manuals. Specifically, add descriptions in the product manuals that intra-board

cross-connections shown in Figure 1 must be configured for the boards listed in the table above if the lasers on

these boards are turned on to test light emitting.

 

Interconnection Between the OLT and the Switch Fails

This topic describes how to troubleshoot the fault when Huawei OLT fails to interconnect

with the switch of another vendor due to incorrect Link Aggregation Control Protocol (LACP)

configuration on the switch.

Fault Type

Other

Keyword

LACP configuration

Interconnection failure

Fault Description

The OLT is connected to a certain type of switch of another vendor in the lacp-static aggregation

mode in the upstream direction. After lacp-static is configured, an alarm is generated, and the

related service is unavailable.

Alarm Information

The alarm generated on the OLT is as follows:

huawei(config)#link-aggregation 0/17 0-1 egress-ingress workmode lacp-static        

huawei(config)#                                                            
! EVENT MAJOR 2008-07-15 13:42:03                                            
  ALARM NAME :Port is forbidden to transfer the service packets               
  PARAMETERS :FrameID: 0, SlotID: 17, PortID: 0                               
huawei(config)#                                                            
! EVENT MAJOR 2008-07-15 13:42:03                                             
  ALARM NAME :Port is forbidden to transfer the service packets              
  PARAMETERS :FrameID: 0, SlotID: 17, PortID: 1

Cause Analysis

  • The upstream optical path of the OLT is faulty.
  • The data configuration of the upstream port on the OLT is incorrect.
  • The LACP configuration is incorrect.
  • The configuration of the peer switch of this vendor is incorrect.

Procedure

Check the configuration of the upstream board on the OLT and the configuration of

the switch. It is found that the interconnected optical ports on the OLT and the

switch are configured as forced 1000 Mbit/s and full duplex, and are in the up state.

Therefore, it can be determined that the fault is not caused by the optical path.

Disable the aggregation function. It is found that the upstream service of a single

link is normal. Therefore, it can be determined that the data configuration of the

upstream port on the OLT is correct.Configure the aggregation manually, and do

not run the LACP protocol. It is found that the services are normal. Therefore,

it can be determined that the fault is caused by the LACP interconnection.

NOTE:

  1. The systems at both ends of the link of the static LACP aggregation group run the
LACP protocol; however, systems at both ends of the link of the manual aggregation
group do not run the LACP protocol.
       2. The switch of this vendor supports both the Port Aggregation Control Protocol  (PAgP)
and LACP, and uses PAgP by default. It is preliminarily suspected that the default protocol
PAgP runs on the switch, which causes interconnection failure. After check, however, it is
found that LACP runs on the switch.
      3. Configure the switch to be in the active LACP mode. The fault then is rectified.

Suggestion and Summary

The switch of this vendor supports the following two LACP modes:
Passive LACP mode (default mode): In this mode, the port is in the passive state, and does
not initiate an LACP negotiation.
Active LACP mode: In this mode, the port is in the active state, and initiates an LACP negotiation.

In this case, the LACP mode is configured on the switch, but an active negotiation is not initiated,

which causes the failure to interconnect with Huawei OLT.

Suggestion: When the LACP mode of the Huawei OLT is set to active LACP (default mode) and the
OLT is connected to the switch of another vendor in the upstream direction after link aggregation:
If the switch of another vendor does not comply with the LACP, this switch must be configured with
the active LACP mode.
If the switch of another vendor complies with the LACP, the LACP negotiation can be initiated regardless
of whether this switch is configured with passive LACP mode or active LACP mode.

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

The main subrack is still in the running state when it is reconstructed into the extended subrack.

At this time, the tributary boards are not reset and thus the new slot IDs cannot be obtained.

As a result, the tributary boards in the extended subrack are displayed as off-service on the T2000.

To solve this problem, remove the boards without IDs and then insert the boards back to obtain the IDs.

Product

OptiX OSN 3500

Fault Type

  • DCN Fault

Others

Symptom

Change the running OptiX OSN 3500 from a main subrack into an extended subrack. Mount the

extended subrack to a newly created OptiX OSN 3500. Query the physical slots of the extended

subrack. It is found that the boards in the extended subrack fail to be displayed and that the tributary

boards in the extended subrack are displayed as off-service on the T2000.

Cause Analysis

The possible causes are as follows:

  • The connection between the main subrack and the extended subrack is faulty.
  • The SCC board in the main subrack and the AUX boards in the main subrack and in the
  • extended subrack are faulty.
  • The tributary boards in the extended subrack are not reset and thus the correct slot IDs
  • cannot be obtained.

Procedure

  1. Check the connection between the main subrack and the extended subrack. It is found
  2. that the connection is normal.
  3. Perform warm reset on the SCC board and the AUX boards in the main subrack and in
  4. the extended subrack. It is found that the problem persists.
  5. Remove the off-service boards and then insert the boards back to force the boards to
  6. perform cold reset. Then, the boards obtain the new slot IDs. The problem is solved.

Reference Information

The following part considers the UXCSB as the cross-connect board of the main subrack and

describes the precautions for the connection between the main subrack and the extended subrack.

Cable connection between the UXCSB and the XCE: The EXA and EXB ports on the UXCSB

board in slot 9 are connected to the EXA ports on the XCE board in slots 59 and 60.

The EXA and EXB ports on the UXCSB board in slot 10 are connected to the EXB ports on the

XCE board in slots 59 and 60. See Figure 1.

The EXT port on the AUX board in the main subrack is connected to the EXT port on the AUX

board in the extended subrack. See Figure 1.

Cover the J9 jumper on the AUX board in the main subrack with the jumper cap and maintain

the J9 jumper on the AUX board in the extended subrack uncapped.

Do as follows to reconstruct a running main subrack into an extended subrack:

    1. Remove the SCC board, line board, and certain unused tributary boards.
    2. Connect the EXT ports on the two AUX boards and remove the J9 jumper on theAUX board in the extended subrack.
    3. Remove the two cross-connect boards.
    4. Insert two XCE boards instead and connect the two XCE boards to the UXCSB boards in the new main subrack.

    After the two cross-connect boards are removed, the extended subrack has no cross-connections. Hence,

  • the tributary boards in the extended subrack are automatically reset. After the J9 jumper is removed from
  • the AUX board, the tributary boards can obtain the new slot IDs (that is, the original ID plus 50).
  • After performing the operations, you need not remove the tributary boards and then insert the boards
  • back again after the configuration.
Figure 1 Cable connection between the main subrack and the extended subrack