Monthly Archives: August 2016

During the Rerouting in the ASON Network, the Protection Switching Time May Exceed the Specification Value

Issue Description

In the networking scenario with the WSS or WSD board, the protection switching

time may exceed the specification value if the optical power is adjusted improperly.

WSS

WSS

For example, in the previous ASON networking, The current route is marked in pink

and the NS2 board is configured with SNCP protection. Reset the FIU board, and

ASON reroutes to the orange path. If the optical power is improperly adjusted at

downstream nodes, the switching time of the SNCP protection group may exceed

the specification value.

Alarm Information

Null

Handling Process

As shown in tests, when the original input optical power of the NS2 board is lower,

the switching performance in the route break-off of the WSD board is better. During

the network design, the optical power of every section must be adjusted strictly in line

with the engineering instructions to ensure that the input optical power of the OTU

board falls in a proper range (at the middle or lower level between the high threshold

and the low threshold). So the protection switching time does not exceed the specification value.

Root Cause

According to the specification provided by component manufacturers, to set considerable attenuation

of the 1×9 WSS 100G module of JDSU used on the WSS or WSD board is a slow process, not a

dramatic drop to the target optical power. The following is the specification provided by component

manufacturers:

WSD

WSD

During the rerouting in the ASON network, the WSD board sets the break-off of the current intra-board

route first and then sets a new intra-board route. After the break-off of the current intra-board is set,

the NS2 board cannot immediately detect LOS and trigger switching if the input optical power of the

NS2 board is close to LOS, because to set the break-off of routes is a slow process. In this case,

certain bit errors may occur, as indicated by the meter of testing the protection switching time.

As a result, the switching time easily exceeds the specification value.

Suggestions

Null

TwitterLinkedInGoogle+FacebookPinterestTumblrStumbleUponRedditShare

Prewarning for ARP Entry Aging Failures on MxU

Keywords: MA5616, Access network product line

Summary

The MxU products use the IPOS protocol stack. After the MxU devices run for a long time

(for example, longer than 497 days), the Address Resolution Protocol (ARP) entry learned

by some MxU devices from the upper-layer device, such as a gateway, cannot automatically

age. In this case, if the upper-layer device is replaced or cut over, and the upper-layer device

does not actively send ARP request packets to the MxU devices, the ARP entry corresponding

to the IP address of the upper-layer device cannot automatically update within a MAC address

aging period. The ARP entry recorded on the MxU devices is the MAC address of the upper-layer

device before the replacement or cutover. As a result, the MxU cannot communicate with the

upper-layer device and accordingly, the management and voice services fail.

Problem Description

Trigger Conditions

This issue occurs if the following conditions are met:

1. The MxU model and version are within the prewarning scope.

2. The system running time is longer than 497 days.

3. The device learns or updates the ARP entry of the upper-layer device when the device has

been running for 496 days.

4. The MAC address of the upper-layer device is changed.

5. The upper-layer device does not actively send ARP request packets to the MxU device to

notify the MxU device of ARP entry updating.

Symptom

The device management or voice service fails.

After the upper-layer device is replaced or cut over, the MAC address of the upper-layer device

in the ARP entry recorded on the MxU is still the original one. In addition, the ARP entry

cannot automatically update within a MAC address aging period.

Identification Method

Perform the following operations to check whether a fault complies with the prewarning:

1. Check whether the MAC address corresponding to the gateway IP address in the ARP

entry on the MxU is the actual MAC address of the gateway. The gateway IP address is

assumed to be 10.144.82.1.

MxU(config)#display arp all

{ <cr>||<K> }:

Command:

display arp all

IP Address      MAC Address    VLAN ID Port    ONT Type

10.144.82.1     00e0-fc64-756d 200     0/0 /0  -   Dynamic

10.144.82.91    001b-2191-b586 200     0/0 /0  -   Dynamic

10.144.83.224   4c1f-cc7d-6393 200     0/0 /0  -   Dynamic

—   3 entries found   —

If the MAC address recorded in the ARP entry is different from the actual MAC address

of the gateway, this fault complies with the prewarning.

2. Check whether the MxU model and version are within the prewarning scope.

3. Check whether the MxU has been running for over 497 days and whether time

reversal occurs on the MxU.

Perform the following operations to determine time reversal:

a) Check and record the system running time (Uptime).

MxU(config)#display version

{ <cr>|backplane<K>|frameid/slotid<S><Length 1-15> }:

Command:

display version

VERSION : MA5616V800R308C02

PRODUCT : MA5616

PATCH:SPC200 SPH518 HP2118

Copyright (c) Huawei Technologies Co., Ltd. 1998-2011 All rights reserved

Uptime is 2 day(s), 5 hour(s), 42 minute(s), 2 second(s)

 

b) Check and record the current system time T1.

MxU(config)#display time

{ <cr>|date-format<K>|dst<K>|time-stamp<K> }:

 

Command:

display time

2014-01-22 02:22:56+08:00

 

c) Check and record the system start time T2.

MA5616(config)#diagnose

 

MA5616(diagnose)%%su

Challenge:ZCZUBOWB

Please input password:

 

MA5616(su)%%display lastwords all

 

+++++++++++++++ Display current lastwords Info: +++++++++++++

 

**********************************************************************

System Start Time            : 2013-01-14 02:07:13.250 , Week: Fri

System Start CpuTick         : 0×00000000 908c5ce3

System Last CpuTick          : 0x000029f3 c89fd402

System Total Running CpuTick : 0x000029f3 3813771f

MilliSecs Per CpuTick        : 0×00010441

System Total Running Time    : 692301.607 (s.ms)

In normal cases, (T1 - T2) = Uptime value. The system time resets and starts timing

again after the device has been running for 497 days. If (T1 - T2) > Uptime value,

time reversal occurs.

If the fault complies with the preceding three conditions, the fault is within the

prewarning scope.

Root Cause

The ARP entry updating failure is caused by a bug of the device software in obtaining

system running time. The system time reverses after the device has been running for

497 days. If the device learns or updates an ARP entry before the time reversal, the

ARP entry becomes abnormal and fails to automatically update within a MAC address

aging period. If the upper-layer device does not actively send an ARP request message

for the ARP entry, the ARP entry does not update.

The following section provides an example to describe the fault cause: The system

running time is assumed to be Tsystem and ARP aging period is AagTime.

l When the device has been running for 497 days (Tsystem = 497), the device learns or

updates an ARP entry. Then, the ARP entry learning time is T1 = Tsystem = 497 and

the next aging time of the ARP entry is Tage = T1 + (AagTime/2) = 497 + (AagTime/2).

l In normal cases, if the system running time Tsystem reaches or exceeds Tage, the ARP

entry ages.

l However, the system time Tsystem reverses if the system running time is longer than

497 days. Therefore, after the device continues running for T’ days, the system running

time Tsystem is T’ (0 + T’). When the next ARP entry aging period starts, the system

running time Tsystem is much less than the ARP entry aging time

Tage [Tage = 497 + (AagTime/2)]. As a result, the ARP entry cannot update or age.

Impact and Risk

The management and voice services on the MxU are affected. The broadband service is

not affected.

Measures and Solutions

Recovery Measures

Run the #reset arp dynamic command on the affected MxU to rectify the fault.

MxU(config)#reset arp dynamic

This operation may take several minutes, please wait…success

Workarounds

The workarounds are the same as recovery measures.

Preventive Measures

l For the MA5612 (H832CCFE), MA5616, MA5621/MA5621A, MA5623A, and

MA5662, upgrade the device to V800R312C00 SPH208.

l For the MA5620/MA5626 (H822EPUB), Huawei will release V800R312C00 SPH209

on February 28, 2014 to resolve this issue.

l For other MxU devices, Huawei will release patches to resolve this issue. For details,

contact the prewarning contact persons.

Prewarning Retraction Conditions

This prewarning can be retracted if issue triggering conditions are not met.

Attachment

None

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

Keywords: ATN, ATN 950

Summary: An ATN device function as a DHCP relay agent, and base stations of two vendors

are connected to different DHCP servers. A server or firewall discards packets sent by a base

station of a specific vendor. As a result, users attached to the base station fail to get online.

[Problem Description]

Usage scenario:

l The login failure occurs only on a Layer 3 HVPN, not on a Layer 2+ Layer 3 L3VPN.

l Base stations of two or more vendors connected to the ATN device attempt to get online

through different DHCP servers.

l Firewall rules are specified for private IP addresses on a wireless network management

system (NMS) to drop packets with IP addresses that are not in the specified wireless

network segment.

Trigger conditions:

The problem occurs if the following conditions are met:

1. An HVPN is configured on an ATN device.

2. Base stations of two or more vendors are connected to the ATN device.

3. The base stations obtain IP addresses assigned by different DHCP servers.

4. Firewall rules are specified for private IP addresses on at least one wireless NMS to

drop packets with IP addresses that are not in the specified wireless network segment.

Symptom:

Users attached to a base station of a specific vendor can get online, and users attached

to a base station of another vendor fail to get online.

Identification method:

1. Query the device version.

Run the display version command in the user view.

<ATN950B-02>display  version

Huawei Versatile Routing Platform Software

VRP (R) software, Version 5.120 (ATN950B V200R002C00SPC300)  //The version matches that involved in this warning file.

Copyright (C) 2011-2013 Huawei Technologies Co., Ltd.

HUAWEI ATN950B uptime is 0 day, 14 hours, 18 minutes

ATN950B version information:

 

 

2. Check that DHCP relay is configured on an L3VPN interface.

Run the display interface GigabitEthernet 0/3/1.200 command in the user view.

In the preceding command, 0 indicates the slot number, 3 indicates the subcard number,

1 indicates the interface number, and 200 indicates the sub-interface number. Specify

these figures based on real-world situations.

<ATN950B-02> display interface GigabitEthernet 0/3/1.200

interface GigabitEthernet0/3/1.200

vlan-type dot1q 200

ip binding vpn-instance LTE-OAM-VPN

ip address 10.109.2.194 255.255.255.252

ip relay address 10.100.64.65  //Specify a DHCP server IP address.

dhcp select relay            //Enable DHCP relay.

 

3. Check that multiple L3VPN interfaces are configured on the ATN device. In addition,

DHCP relay is enabled and different DHCP server IP addresses are specified on the interfaces.

Run the display interface GigabitEthernet 0/3/2.200 command in the user view.

In the preceding command, 0 indicates the slot number, 3 indicates the subcard number,

2 indicates the interface number. and 200 indicates the sub-interface number. Specify these

figures based on real-world situations.

<ATN950B-02> display interface GigabitEthernet 0/3/2.200

interface GigabitEthernet0/3/2.200

vlan-type dot1q 300

ip binding vpn-instance LTE-OAM-VPN

ip address 10.109.2.184 255.255.255.252

ip relay address 10.100.65.65  //Specify a DHCP server IP address, which is different from that displayed in the command output in step 1.

dhcp select relay            //Enable DHCP relay.

 

4. A DHCP login failure occurs

Note that when users attached to a base station fail to get online using DHCP through an

ATN device, the ATN device needs to be notified of the event from the wireless side.

[Root Cause]

No RFC defines which source IP address is added to a DHCP Request message to be

forwarded by a DHCP relay agent. The ATN device automatically users the IP address of

an outbound interface as the source IP address and adds it to a DHCP Request message in

a VRF or native IP scenario.

In an L3VPN scenario, an ATN device functioning as a DHCP relay agent sets the source

IP address to the first valid private IP address in a VRF for all DHCP Request messages.

The base station of each vendor is connected to a specific NMS that functions a DHCP

server for the ATN device. NMS server hardware or firewall rules are specified for private

IP addresses to drop packets with IP addresses that are not in the specified network

segment. As a result, the DHCP Request message in which the source IP address

should have been set to the second valid private IP address in a VRF carries the

first valid private IP address in a VRF and therefore is dropped.

[Impact and Risk]

Users on a base station attached to the ATN device fail to get online using DHCP.

[Measures and Solutions]

Recovery measures:

Run the ip relay source-ip-address 24.1.1.2 command on the faulty DHCP

relay-enabled interface of the ATN device. 24.1.1.2 is the source IP address to be

carried in DHCP Request messages.

Note that 24.1.1.2 is the IP address of an interface connected to a base station.

<ATN950B-02> display interface GigabitEthernet 0/3/2.200

vlan-type dot1q 300

ip binding vpn-instance LTE-OAM-VPN

ip address 24.1.1.1 255.255.255.252

statistic enable

ip relay address 10.100.65.65

dhcp select relay

ip relay source-ip-address 24.1.1.2   //Add this command.

 

Workarounds:

Run the ip relay source-ip-address 24.1.1.2 command on the faulty DHCP relay-enabled

interface of the ATN device. 24.1.1.2 is the source IP address to be carried in DHCP Request messages.

<ATN950B-02> display interface GigabitEthernet 0/3/2.200

vlan-type dot1q 300

ip binding vpn-instance LTE-OAM-VPN

ip address 24.1.1.1 255.255.255.252

statistic enable

ip relay address 10.100.65.65

dhcp select relay

ip relay source-ip-address 24.1.1.2   //Add this command.

 

Solutions:

Install one of the following patches to a specific type of ATN device running a specific version.

After the patch is installed, the ip relay source-ip-address command is automatically added.

l On ATN 910 and ATN 950 devices running versions earlier than V200R001C02SPC200,

upgrade them to V200R001C02SPC200 and install the patch V200R001SPH009 or later.

l On ATN 910 and ATN 910I devices running V200R002C00, install the patch

V200R002SPH005 or later.

l On ATN 950B devices running versions earlier than V200R001C02, upgrade them to

V200R001C02 and install the patch V200R001SPH008 or later.

l On ATN 950B devices running V200R002C00, install the patch V200R002SPH002 or later.

Warning of an ARP Entry Dually-Transmitting Failure

Keywords: ATN 950B, ARP entry dually-transmitting failure, mixed VPN solution

Summary: A timing sequence error occurs when software performs batch backup on an

ATN 950B NE functioning as a CSG running V200R002C00SPC300 or an earlier version.

After a master/slave MPU switchover is performed several times, there is a possibility that the

ARP entry dually-transmitting function fails. In this case, when network-to-user traffic transmitted

along an MPLS LDP LSP reaches the slave ASG in the mixed VPN solution, the ARP entry

dually-transmitting failure causes a service interruption.

[Problem Description]

Usage scenario:

 

scenario

scenario

In a mixed VPN solution, LDP LSPs are established on the access ring network. ATN 950B NEs

functioning as CSGs use the L2VPN function to transmit services and support the ARP entry

dually-transmitting function configured using the mpls l2vpn arp-dual-sending command

shown in the following table.

interface Ethernet0/3/0.1

mtu 2000

vlan-type dot1q 1

mpls l2vc 100.0.0.3 100 control-word raw//Configure the primary PW destined for ASG3.

mpls l2vc 100.0.0.4 101 control-word raw secondary//Configure the secondary PW destined for ASG4.

mpls l2vpn redundancy master//Configure PW redundancy protection to work in master/slave mode.

mpls l2vpn reroute delay 300//Set the delay for a PW switchback to 300s.

mpls l2vpn stream-dual-receiving//Configure the dually-receiving function for the primary and secondary PWs to prevent traffic loss during a traffic switchback.

mpls l2vpn arp-dual-sending //Configure ARP entry dually-transmitting function on both PWs to minimize traffic loss if a fault occurs on the primary PW.

Trigger conditions:

There is a high probability that the problem occurs if the following conditions are met. In the

laboratory, the probability is approximate 70%.

1. An MPU is reseated or the slave switchover command is run to perform a master/slave MPU

switchover twice. Alternatively, the slave MPU is reseated or a command is run to reset the slave MPU.

2. Another master/slave MPU switchover is performed.

Note that there is no limit on the interval between master/slave MPU switchovers, and the ATN 950B

NE must not be reset between master/slave MPU switchovers.

Symptom:

The slave ASG fails to learn the ARP entry mapped to the nodeB or eNodeB. As a result,

network-to-user traffic on the slave ASG is interrupted.

Identification method:

1. Check the tunnel token value of an L2VPN tunnel on the ATN 950B NE.

Run the display mpls l2vc interface interface-type interface-number command in the user view.

<HUAWEI>display mpls l2vc interface Ethernet0/3/0.1 

//In real-world situations, change Ethernet0/3/0.1 to the name of the actual interface that transmits L2VPN services.
*client interface       : Ethernet0/3/0.1 is up
Administrator PW       : no
session state          : up
AC status              : up
VC state               : up
Label state            : 0
Token state            : 0
VC ID                  : 1
VC type                : Ethernet
destination            : 172.1.1.178
local VC label         : 26           remote VC label      : 26
local AC OAM State     : up
local PSN OAM State    : up
link state             : up
local VC MTU           : 1500         remote VC MTU        : 1500
local VCCV             : cw alert ttl lsp-ping bfd
remote VCCV            : cw alert ttl lsp-ping bfd
local control word     : enable       remote control word  : enable
tunnel policy name     : –
PW template name       : –
primary or secondary   : primary
load balance type      : flow
Access-port            : false
Switchover Flag        : false
VC tunnel/token info   : 1 tunnels/tokens
NO.0  TNL type       : lsp   , TNL ID : 0×5  //0×5 is the token value used by the L2VPN tunnel. The token value is a hexadecimal number.
    Backup TNL type      : lsp   , TNL ID : 0×9

 

Check the MAC address carried in dually transmitted ARP packets.Run the display mplsada lsp

token 5 command in the diagnostic view. Note that 5 is the token value obtained in Step 1.

Note that when the problem occurs, the destination MAC address carried in dually transmitted ARP

packets is all 0s.

<HUAWEI>system-view

[HUAWEI]diagnose

[HUAWEI-diagnose]display  mplsada lsp token  5 //5 is the tunnel token value obtained in Step 1. This tunnel token value is a decimal number.

ulPdtHandle                     : 434410400
Protect Type          :3
Lsp or gre index      :5
Protect groupid       :1
ApsId                 :515
Primary pdthandle     :0x19e493a0
Backup pdthandle      :0x19df16d8

Nhi list begin
Nhi list end.  List count  :2

Main product info(TunnelId 5):
Ovid                  :0
MacIndex              :7
OutIfIndex            :337
TrunkorTp             :14
Trunk flag            :0
Nexthop               :0xc8010102
TunnelId              :5
Mac fake flag         :0
Exp Mode              :0
Exp value             :0
TnlType               :0
DestMac               :00:00:00:00:00:00 //The DestMac field indicates the destination MAC address for dually transmitted ARP packets. When the problem occurs, the destination MAC address is all 0s.

SrcMac                :f4:a1:a2:cf:33:01
Egress Intf index     :138
Mpls Tunnel index     :8
LspId or GreId        :4294967295
FqId                  :0
Dsid                  :0
Out stattisticId      :4294967295

 

[Root Cause]

1. When an ATN 950B is running properly, its master MPU is in slot 7, and the slave MPU is in slot 8.

After a master/slave MPU switchover is performed by reseating an MPU or running commands, the

MPU in slot 7 becomes the slave one, and the MPU in slot 8 becomes the master one. The MPU in

slot 7 synchronizes data in a batch with the MPU in slot 8. Due to a timing sequence error, LDP

data is backed up earlier than ARP data. As a result, the destination MAC address on the MPU in

slot 7 is all 0s. Although the destination MAC address is incorrect, the MPU in slot 7 does not

transmit services, and therefore, services are not affected.

2. After the other master/slave MPU switchover is performed, the MPU in slot 7 becomes the

master one. This MPU forwards dually transmitted ARP packets carrying the destination MAC

address of all 0s. Upon receipt, the next-hop device considers the packets incorrect and discards

them. As a result, the slave ASG fails to learn the ARP entry.

[Impact and Risk]

When network-to-user traffic arrives at the slave ASG, traffic is interrupted.

[Measures and Solutions]

Recovery measures:

Note that the recovery measures will adversely affect services transmitted on the ingress,

transitnode, and egress along an existing tunnel within seconds.

Run the reset mpls ldp all command in the user view to reset MPLS LDP.

<HUAWEI> reset mpls ldp all

 

Workarounds:

Solutions:

Perform either of the following steps to resolve the problem:

l Install the patch V200R002SPH006 or later on the ATN 950B NEs running V200R002C00SPC300.

l Upgrade a version earlier than V200R002C00SPC300 to V200R002C00SPC300 and then install the patch V200R002SPH006 or later.

When Slave Main Control Board Unregistration on an ATN 950B

Keywords:

ATN 950B, slave main control board, unregistered

Summary:

On an ATN 950B equipped with the AND2CXPE/AND2CXPA/AND2CXPB boards, software does not send

packets in the defined order, causing communication failures between the master and slave main control boards.

As a result, the slave main control board fails to be registered.

 

[Problem Description]

Application scenario:

The AND2CXPE/AND2CXPA/AND2CXPB boards function as the master and slave main control boards on

an ATN 950B.

Trigger conditions:

There is a low probability that the problem occurs if the AND2CXPE/AND2CXPA/AND2CXPB boards function

as the master and slave main control boards on an ATN 950B.

Symptom:

The slave main control board cannot be registered.

Identification method:

1. Check the type of the main control boards.

Run the display version command in the user view.

 

This problem occurs only on the ATN 950B on which the AND2CXPE/AND2CXPA/AND2CXPB boards function

as the master and slave main control boards.

[huawei]display  version

……

CXPB(Master) 7  : uptime is 18 days, 22 hours, 36 minutes

StartupTime   2014/07/14   16:19:41

SDRAM Memory Size   : 1024M bytes

FLASH Memory Size   : 128M bytes

CFCARD Memory Size : 498M bytes

RAMDISK Memory Size : 10M  bytes

ANDD00CXPB01 version information

PCB         Version : AND2CXPB REV C  //This warning is involved only when the value AND2CXPE, AND2CXPA, or AND2CXPB is recorded here.

 

2. Check the board registration status.

Run the display device command in the user view.

[huawei]display  device

ATN950B’s Device status:

Slot #    Type       Online    Register      Status      Primary

- – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - -

1         PIC        Present   Registered    Normal      NA

2         PIC        Present   Registered    Normal      NA

3         PIC        Present   Registered    Normal      NA

4         PIC        Present   Registered    Normal      NA

7         CXP        Present   NA            Normal      Master

8         CXP        Present   Unregistered  Abnormal    Slave//Indicates that the slave main control board is not registered.

9         PWR        Present   Registered    Normal      NA

10        PWR        Present   Registered    Normal      NA

11        FAN        Present   Registered    Normal      NA

 

3. Check the cause of the board reset. Information on the master main control board shows that the slave main

control board encountered an HA failure.

Run the display board-reset 8 command. The parameter 8 indicates the slot number of the unregistered board.

[huawei-diagnose]display  board-reset 8

CXP8 reset information:

– 1. DATE:2014-06-23  TIME:02:15:41  RESET Num:4

–    Reason:VRP HA Module reset slave board //Indicates that the slave main control board is reset due to an HA failure.

 

[Root Cause]

In some cases, software does not send packets in the defined order, causing communication failures between

the master and slave main control boards. As a result, the slave main control board fails to be registered.

 

[Impact and Risk]

The slave main control board is not registered and fails to back up the master main control board.

 

[Measures and Solutions]

Recovery measures:

Install a patch on the ATN 950B.

Workarounds:

None

Solutions:

Install the V200R003SPH005 patch or later on the ATN 950B V200R003C00SPC200/ ATN 950B V200R003C10SPC100.

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

Issue Description

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

Alarm Information

Null

Handling Process

(1) All the VCTRUNK support flow control

As for all the EFT boards (EFT4, EFT8 and EFT8A), all the vctrunk support flow control.

(2) The flow control mode is irrelevant to the working mode

No matter the working mode is auto-negotiation or forced mode, use ::ethn-cfg-set-fcmode:

to set flow control mode.

(3) The flow control test has two directions: equipment to meter, and meter to equipment. 

The common test mode is from equipment to meter. The meter transmits traffic larger than the upper

bandwidth of the vctrunk, the equipment transmits flow control frame to meter, and the meter reduces

the traffic transmitted.

The test mode from meter to equipment indicates that the meter transmits flow control frame to the

equipment to see the equipment transmits the flow control frame or discards it. The EFT board discards

the flow control frame.

(4) Precautions on flow control test

If testing the flow control of negotiation, note the operation of the meter when using SMB to test.

Set the MII register of the corresponding port of the meter, mark the tenth bit of the fourth register.

And then click the auto-negotiation button again. This is a bug of the meter. Specific procedure is as follows:

(1) Right click, select “MII register”.

MII register

MII register

(2) Then, select “Reg4″, mark the “pause capable” of the tenth bit.

Reg4

(3) At last, click “Restart Auto Negotiation”.

Restart Auto Negotiation

Restart Auto Negotiation

 

 

 

Root Cause

Null

Suggestions

Null

 

 

OSN3500

OSN3500

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

Issue Description

SLQ4 board is hardly fully utilize in slot 1 to slot 4 in OSN 3500 although the

slot capacity can support until 5G.
NG-SDH manual:
When the cross-connect capacity is 80 Gbit/s or 200 Gbit/s(S/I XCS),

for the board housed in any of slots 1–4 and 15–16two optical interfaces

can be configured. For the board housed in any of slots 5–8 and 11–14, four

optical interfaces can be configured.

Alarm Information

NULL

Handling Process

The Slot 1 to 4 of OSN 3500 was created for the utilization of the smaller capacity

service board. So SLQ 4 is pretty suggested on slot 4 above .

Root Cause

The cross-connect board (N1E/IXCSA/B) supports two compatible backplane rates

of 622M and 2.5G. Other boards support only one fixed backplane rate. The N1SLQ4

needs 4 buses at a rate of 622M. The cross-connect board (N1E/IXCSA/B) has two

buses in slots 1–4 and 15–17, four buses in slots 5, 6, 13 and 14, and 16 buses in slots 7, 8, 11

and 12. Therefore, the SLQ4 can be installed only in for 2 optical boards which can connect to 2 buses.
The cross-connect board supports two compatible backplane rates of 622M and 2.5G.

Other boards support only one fixed backplane rate. Hence, consider both the access

capacity of each slot and the bus distribution of the cross-connect board for board installation.

This method also works for other line boards.

Suggestions

The backplane designed can be improved for this situation to giving customer more option for

utilization on different capacity service board on the sub rack OSN .

 

DSC01773

Access Capacity of Slots of the OptiX OSN 1500 V1R2

Issue Description

Access Capacity of Slots  of the OptiX OSN 1500

Alarm Information

None,

 

Handling Process

None,

 

Root Cause

Slots 11, 12 and 13 of the OptiX OSN 1500 can be divided into smaller slots as needed. Figure 1-1 and

Figure 1-2 give the access capacity of each slot before and after division of the three slots, respectively.

Figure 1-1 Access capacity of each slot before division of the three

slots

slots

 

Figure 1-2  Access capacity of each slot after division of the three slots

slots

slots

Suggestions

None,

 

OSN 1500

OSN 1500