· 2017-10-17 · the documentation. 45245 a bic sometimes shuts down autonomously due to a false...

Copyright © 2017 Juniper Networks, Inc. ALL RIGHTS RESERVED.

BTI7800

Release 4.2.1

Release Notes

Rev. 01

October 2017

BTI7800 Release 4.2.1 ii



This product is the property of Juniper Networks, Inc. and its licensors, and is protected by copyright. Any reproduction in whole or in part is strictly prohibited. Juniper, Juniper Networks, BTI, BTI SYSTEMS, packetVX, proNX, and The Network You Need are trademarks or registered trademarks of Juniper Networks, Inc. and/or its subsidiaries in the U.S. and/or other countries.

Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice.

Copyright 2003-2016 BTI Systems, Inc. All rights reserved.

BTI7800 Release 4.2.1 iii


Obtaining technical support

Technical product support is available through the Juniper Networks Technical Assistance Center (JTAC). If you are a customer with an active J-Care or Partner Support Service support contract, or are covered under warranty, and need post-sales technical support, you can access our tools and resources online or open a case with JTAC.

You can open a case with JTAC on the Web or by telephone. • Use the Case Management tool in the CSC at http://www.juniper.net/cm/.

• Call 1-888-314-JTAC (1-888-314-5822 toll-free in the USA, Canada, and Mexico). For international or direct-dial options in countries without toll-free numbers, see http://www.juniper.net/support/requesting-support.html.

End User License Agreement

The Juniper Networks product that is the subject of this technical documentation consists of (or is intended for use with)

Juniper Networks software. Use of such software is subject to the terms and conditions of the End User License

Agreement (EULA) posted at http://www.juniper.net/cm/. By downloading, installing or using such software, you agree to

the terms and conditions of that EULA.

Document Identification

Juniper Networks BTI7800 Release 4.2.1 Release Notes Rev. 01

Abstract

This document provides information related to the current release.

Publication History

Revision Date Changes

01 October 2017 Baseline

http://www.juniper.net/cm/

http://www.juniper.net/support/requesting-support.html

http://www.juniper.net/cm/

BTI7800 Release 4.2.1 iv


BTI7800 Release 4.2.1 v


Contents

1. Introduction .................................................................................. 1

1.1 Purpose ....................................................................................................... 1

1.2 New Features .............................................................................................. 1

1.3 Upgrade Information .................................................................................. 2

1.4 Restrictions ................................................................................................ 2

1.4.1 Filler Module (BT8A78FLR7) ................................................................ 2 1.4.2 BTI7801 Chassis (BT8A78CH1) ........................................................... 2

1.5 proNX Service Manager ............................................................................. 2

2 Resolved Issues .......................................................................... 3

3 Known Issues............................................................................... 5

4 Known Limitations .................................................................... 11

5 Related Documentation ............................................................ 14

BTI7800 Release 4.2.1 vi


BTI7800 Release 4.2.1 1


1. Introduction

1.1 Purpose

This document lists the BTI7800 software features, known software issues, and fixed

software issues in releases 4.2 and 4.2.1.

1.2 New Features

BTI7800 Series releases 4.2 and 4.2.1 provide support for the following:

UFM6 (BT8A78UFM6-I02) module

o QPSK modulation for the 400G Coherent MSA XCVR:

Longer reach versus 16-QAM modulation

Single OTU4 per optical channel

Supports two different types of soft decision FEC (soft-fec and

sd-fec-25pc)

Can interoperate with existing UFM3 and UFM4 100-Gbps

coherent solutions (using soft-fec)

o QSFPP-4X10GD-LR multi-rate client-side transceiver:

Fixed 1310-nm wavelength

Supports four independent 10-Gbps interfaces

Compatible with the existing MTP-4LC-Sxx breakout cables,

BT8A78CAS1 fiber cassette, and BT8A78RCK1 Fiber

Management Rack

Supports the following 10-Gbps client signals (protocols):

OTU2

OTU2e

OC192/STM64

10GbE

o Supports the following additional transport applications:

Up to 40x10-Gbps client signals (QSFPP-4X10GD-LR and/or

QSFPP-4X10GE-LR) into 2x200-Gbps line signals

Up to 20x10-Gbps client signals (QSFPP-4X10GD-LR and/or

QSFPP-4X10GE-LR) into 2x100-Gbps line signals

Up to 20x10-Gbps (QSFPP-4X10GD-LR and/or QSFPP-

4X10GE-LR) and 2x100GbE (QSFP-100G-LR4-2) client signals

into 2x200-Gbps line signals

Up to 10x10-Gbps (QSFPP-4X10GD-LR and/or QSFPP-

4X10GE-LR) and 1x100GbE (QSFP-100G-LR4-2) client signals

into 2x100-Gbps line signals

NOTE: Restrictions exist for different protocol combinations. See the

BTI7800 Series Software Configuration Guide for details.

UFM3 (BT8A78UFM3):



o Supports 100GbE-to-100GbE cross-connect

96-Channel Amplifier (BT8A78AMP1) support on the BTI7801 chassis

Ability to restore a backed-up database to any chassis of the same chassis type

(BTI7801 to BTI7801, BTI7802 to BTI7802, BTI7814 to BTI7814) type

Improved CMM failure handling

ODU Mismatch and ODTG Mismatch alarms to detect ODU and ODTG

misconfiguration

1.3 Upgrade Information

You can upgrade to Release 4.2.1 from Releases 1.5.x, 1.6, 1.7, 2.1.x, 4.1, and 4.2.

Contact Juniper Networks Support if you would like to upgrade from a release different

from the above.

1.4 Restrictions

1.4.1 Filler Module (BT8A78FLR7)

The BT8A78FLR7 filler module must be used to cover empty slots in a BTI7814 chassis

running release 2.1.0 software or higher. See the following TIB for more information: BTI-

TIB002-2016.

1.4.2 BTI7801 Chassis (BT8A78CH1)

The BTI7801 requires a CMM running software release 2.1.0 or higher and CMM SHMM

firmware that is packaged in release 2.1.0 and higher.

If you are installing software on a BTI7801, ensure that the CMM is running SHMM

firmware from release 2.1.0 or higher. If the CMM is not running SHMM firmware from

release 2.1.0 or higher, you must upgrade the CMM SHMM firmware immediately after

commissioning the system with the new software. The SHMM firmware is included in the

software package for this release. See the section, Upgrading the CMM Firmware, in the

BTI7800 Software Configuration Guide for information on how to upgrade the CMM

SHMM firmware.

1.5 proNX Service Manager

BTI7800 Series Release 4.2.1 is supported by PSM Release 7.4 or higher.



2 Resolved Issues

The following issues have been resolved in releases 4.2 and 4.2.1:

Issue Description

45820 Unseating a UFM6 card from the chassis sometimes causes both CMMs to

warm reload.

45794 An Equipment Missing (eqptMiss) alarm for a fan is sometimes cleared even

if the fan is still missing from the system.

45789 A warm reload of a CMM might cause a warm reload of all traffic modules in

the system.

45780 The show tech-support command sometimes fails to create the tech-

support archive.

45768 An Equipment Missing (eqptMiss) alarm is sometimes raised against

equipment that is present, resulting in interfaces going down on the affected

equipment.

45742 After a system has been running for a while, the standby CMM will raise a

Memory High Usage (memHighUsage) alarm.

45374 When you warm reload the active CMM in a chassis with an active and a standby CMM, the standby CMM might take up to a second to take over, causing the chassis to run briefly without an active CMM. This sometimes causes the service modules to warm reload. This is not service affecting.

45349

45305

When warm reloading a UFM after changing the time on a chassis, some

transceivers become operationally down. This is a procedural issue within

the documentation.

45245 A BIC sometimes shuts down autonomously due to a false temperature

sensor reading.

45197 A UFM3/UFM4 sometimes raises a spurious eqptBrownout alarm causing

the UFM to cold reload.

45082 The show protection wavelength table command does not always display

the current optical power values on WPS ports.

44728 The PEM might occasionally raise a spurious eqptMiss (Equipment Missing)

alarm. The alarm eventually clears by itself and you do not need to take any

action.

44506 The show statistics current <interface> binLength command sometimes

returns a VALIDITY of notAvailable for some bin lengths. This command

should not be allowed. The CLI should only allow you to use the binLength

option when you specify a bin.



Issue Description

44449 After you restore both CMMs in a chassis to their factory default

configuration, the CLI might not return information on some show

commands.

44432

44501

The PEM might occasionally raise a spurious powerAbsent (No Power

Available) alarm.

44374 When a UFM is reseated or cold reloaded, its operational state might remain

disabled.

44257 If you delete a disabled UFM interface and create a new interface at that

same location with a different protocol, the new interface might generate an

AIS (for example, an MS-AIS for SDH interfaces) after you set up the

subsequent cross-connect.

43226 The system upgrade firmware l2-switch command might occasionally fail

to upgrade the L2-switch firmware.

41960 Not all IP management addresses may be reported in the IP MIB. The

problem is in the reporting of the IP MIB only. Management connectivity is

not affected.

41917 If the system time changes (including changes due to daylight savings

switchover), the show statistics historical command may display an

“Internal error” message in the 1Day bin in which the time change occurs.

The other 1Day bins are correct.

41639 If you manually upgrade the SHMM firmware on the CMMs immediately after

upgrading the L2-switch firmware, one of the CMMs may disappear from the

system, and an Equipment Missing (eqptMiss) alarm is raised.

41615 After the SHMM firmware is automatically upgraded, one of the CMMs may

raise a spurious SHMM Firmware Upgrade Required (firmUpgrdReqd) alarm.

41528 The CLI allows historical statistics bins to be deleted, but this capability is not

supported.

37350 A communication timeout can occur between the two CMMs or between the

CMM and a UFM, leading to an Equipment Management Communications

Failure (eqptComm) alarm. Traffic is not affected when this occurs.



3 Known Issues

The following are known issues in this release:

Issue Description

45857 Upon replacing a CMM in a dual CMM system, the newly inserted CMM might not upgrade the SHMM firmware automatically. Traffic is not affected.

Workaround: Perform a system reload warm cmm of the newly inserted CMM.

45856 After swapping a CMM in a chassis, the new CMM might raise a false Equipment Missing (eqptMiss) alarm on a UFM that is not missing. Traffic is not affected.

Workaround: Contact JTAC.

45853 A software upgrade might occasionally fail with a status of “FAIL (-1) - Internal error”. Traffic is not affected.

Workaround: If this occurs, download the software image and try the upgrade again.

45850 When performing a software upgrade on a multichassis system, the CMMs in the satellite chassis might occasionally fail to upgrade. Traffic is not affected.

Workaround: Perform a system reload warm cmm of the failed CMMs one

at a time. Wait until the first reloaded CMM is up and running before reloading the second CMM.

45842 When a UFM6 line port is configured for QPSK modulation, the FEC BER

PM calculated and displayed for that port is underestimated by

approximately 50 percent.

Workaround: None

45828 After performing a software upgrade, some interfaces might show a laser

status of ‘off-eqpt’. Traffic is not affected.

Workaround: Perform a system reload warm cmm of the active CMM.

45802 Pulling the BIC latch on a BIC (for example, as part of BIC replacement)

might cause the second BIC on the same UFM3 to briefly go out of service.

This issue affects cross-connects local to the second BIC only.

Workaround: None

45801 When you repeatedly provision and delete an optical channel on a UFM6,

the system might raise an Equipment Fail (eqptFail) alarm for the UFM.

Workaround: None

45779 If a BIC’s state toggles repeatedly such as when you repeatedly perform a

cold reload of the containing UFM module, the BIC might transition and

remain in Down state.

Workaround: Perform a system reload warm ufm command for the

containing UFM.



Issue Description

45758 An Equipment Mismatch (eqptMism) alarm for a BIC does not cause the BIC

(red) Fail LED to turn on. The LEDs remain unchanged.

Workaround: None

45756 When you install a Coherent CFP into a BIC/UFM, the system might raise

and then clear an Equipment Fail (eqptFail) alarm for the CFP.

Workaround: None. The system clears the alarm automatically.

45735

45791

If you use the commissioning shell in an existing running system to reset a

CMM to factory defaults for the purpose of creating a brand new

configuration, the CMM and the UFMs might get out of synchronization,

leading to a mismatch between the new database and the configuration

currently running on the UFMs. This issue does not apply to CMM

replacement where you restore the database from a backup instead of

creating a brand new configuration.

Workaround: After resetting the CMM to factory default from the

commissioning shell, perform a system reload all cold CLI command

before configuring the system. Do not use this workaround for CMM

replacement. This workaround is not needed in that situation.

45372 After a power cycle where power is lost temporarily on all feeds, some

service modules might not boot back up in rare situations.

Workaround: Perform a system reload warm cmm on the active CMM.

This command does not affect service on the modules that have come up

and are carrying traffic.

45257 The Fault LED on the line or client port on the BT8A78AMP1 module might

remain lit even after you deprovision the module from the optical group. This

is purely cosmetic as the module is not provisioned to carry traffic.

Workaround: Perform a cold reload of the module (system reload cold

module).

44332 If the name of a dol och endpoint contains an underscore, and you try to set

up a dol och-xcon cross-connect with that endpoint, the BTI7800 returns an

“invalid value” error.

Workaround: Delete the dol och endpoint and recreate it with a name that

does not contain an underscore.

44167 The CLI allows you to delete a DOL object whose admin-status is up. This

should not be allowed.



Issue Description

42687 To properly delete an optical channel cross-connect, you must also delete

the line port optical channels.

Workaround: The proper procedure to delete optical channel cross-

connects is as follows:

1) Use the no dol och-xcon endpoint1 endpoint2 command to delete

the cross-connect.

2) Use the no dol och:identifier command to delete the line port OCH

endpoint.

42600 A single BTI7800 system (either single or multi-chassis) supports the

following limits:

A maximum of 4 ROADM modules. The other slots can be

populated with other BTI7800 modules but cannot be populated with

ROADM or ILA modules.

A maximum of 2 ILA modules. The other slots can be populated with

other BTI7800 modules but cannot be populated with ROADM or

ILA modules.

42039 The show statistics current oms and show statistics current osc

commands return inaccurate average and standard deviation values at the

beginning of a bin interval.

Workaround: To obtain more accurate values, issue the command again

near the end of the bin interval.

41089 During an L2-switch firmware upgrade on the CMM, management

connectivity may be lost temporarily.

41027 The show dol fiber-conn command sometimes shows the Far End (FE)

endpoints between a UFM interface and a mux/demux client port as “NOT-

CONNECTED”. This text is misleading and should be ignored. The system is

not supposed to display the Far End endpoints for this type of fiber

connection.

40829 When the active CMM in a dual-CMM chassis is warm reloaded, the output

of the show equipment command shows the reloading CMM as

operationally up before it has actually come back up.

40781 The Far End Configuration Inconsistent (feci) alarm is raised against the osc

component when it should be raised against the port component.

40661 If you specify a metric when you delete a management static route (i.e. no

mgt static ip_address interface interface metric), the CLI accepts

the command but does not delete the static route.

Workaround: When you delete a static route, do not specify the metric (i.e.

no mgt static ip_address interface interface).

40616 A Firmware Upgrade Required (firmUpgrdReqd) alarm may be raised

spuriously against the CMM after a cold reload of the system.

Workaround: Perform a warm reload of the CMM to clear the alarm.



Issue Description

40514 The show dol och-power command can only be run from one CLI session

at a time. If the command is run from more than one CLI session

concurrently, the command might return an error.

Workaround: If the problem occurs, retry the command from a single CLI

session.

39954

39810

Active conditions against dol components do not appear in the show

conditions output when the component against which the conditions exist is

administratively down.

Workaround: Enable the component to see the outstanding conditions.

39940 When the management IP address is changed and auto-provisioning is

enabled, the ROADM node and connected nodes may automatically create

new fiber connections and raise Far End Identification Mismatch (feim)

alarms. Traffic is not affected.

Workaround: Perform the following procedure to change the management

IP address:

1. Turn auto-provisioning off (system auto-prov false) on the target

node and on all connected nodes. The target node is the node where

you want to change the management IP address. A connected node

is a node that has a fiber connection to the target node.

2. On the target node, change the management IP address.

3. On each connected node, delete any fiber connection whose

endpoint refers to the target node’s previous management IP

address.

4. On each connected node, create a new fiber connection to the target

node. Use the target node’s new management IP address.

5. On both the target node and the connected nodes, re-enable auto-

provisioning if desired (system auto-prov true).

39898 When an OMS or OSC component is disabled and then re-enabled, the

show statistics command may not show the disabled and re-enabled

component in the CLI auto-completion list.

Workaround: Specify the full component name instead of relying on the CLI

auto-completion feature.

39803 When a user issues a system reload command but does not respond

affirmatively to the confirmation dialog, the command returns a prompt and

appears in the log file as if the command was executed when in fact it was

not.

39773 If the PRE module is enabled when there are no optical channels configured

on the line, the system may raise an Automatic Power Reduction (apr) alarm

on the host module PRE port. The alarm should clear when optical channels

are configured.



Issue Description

38476 When repeatedly removing a pluggable transceiver and inserting a new one

in its place, a spurious Equipment Mismatch (eqptMism) alarm may be raised

even though the final insertion did not result in a mismatch.

Workaround: If this problem occurs, remove the transceiver and re-insert it

after 30 seconds. To avoid this problem, after removing a transceiver, wait

30 seconds before inserting a new one in.

35898 When deleting and adding an OCH cross-connect (och-xcon) where the new

cross-connect contains an endpoint that is in the deleted cross-connect, the

new cross-connect may not be set up properly.

Workaround: After deleting the old cross-connect, commit the changes

before adding the new cross-connect.

35068 The show amp commands may display incorrect power values.

Workaround: Use the show statistics current command for the amplifier

instead.

34338 The show statistics command for UFMs displays an incorrect name for the CPU load average value. The displayed name is always “CPU 1-minute load avg.”, which may be misleading.

33501 De-provisioning a CMM as a system controller (no system controller-1) and then adding it back (system controller-1) within a short time period might cause the CMM to come up in an incorrect state.

Workaround: After de-provisioning a CMM, wait until the other CMM

becomes active before adding the de-provisioned CMM back.

32149 When a module is replaced in a chassis, the CLI commands show system version and show system firmware will not display the correct software and firmware information for this module until the operational state of the module changes to UP. Prior to this occurring, the output displays the software and firmware versions of the previous module.

31812 De-provisioning a CMM while another CMM is synchronizing with it might lead to an unrecoverable error that requires a software reinstallation from a USB system repair drive.

Workaround: Wait until the CMMs are synchronized before de-provisioning a CMM. The CMMs are synchronized when the show system command displays the HA Status as In Sync.

30642 The AINS countdown timer is not preserved over an SCM (System Control Management module) failover.

30630 Provisioning tasks cannot be performed during a system upgrade.

28745 The actions of the following commands are not completed until the next system restart:

system database restore remote-url

system upgrade remote-url path



4 Known Limitations

Known limitations are issues that are not planned to be resolved, and that may not be

described in the documentation set for this release. These limitations may be described in a

future release of the documentation set where applicable and necessary. Once a limitation is

described in the documentation set, the limitation may be removed from this list (without

notice).

Issue Description

44703 The show tech-support command sometimes outputs the following

message repeatedly: 0% collecting card files from all CMM's : {cmm:2/B, 0%} {cmm:1/A, 0%}

{cmm:1/B, 0%} ... and 1 other cards

Workaround: This problem is caused by core files using too much disk

space. Use the debug-utils delete-core-files command to remove core

files.

44502 If a 10GE or 100GE client port on a UFM6 module receives a non-Ethernet

signal, the port raises an los (Loss of Signal) alarm instead of an loSync

(Loss of Synchronization) alarm.

44468 The upgrade from a pre-4.1 release to release 4.1 or later might fail if this is

the first time you are upgrading the pre-4.1 system (to any release) after you

commissioned it. When the upgrade fails, the show system upgrade

command displays a Current Status of commit-failed.

Workaround: If this occurs, try the system upgrade remote-url, system

upgrade download, and system upgrade commit commands again. Note

that you should retry all three commands even if the show system upgrade

command indicates that the original download was successful.

44442 In releases 4.1 and earlier, the system upgrade firmware shmm command

might occasionally fail to upgrade the SHMM firmware.

Workaround: If the system upgrade firmware shmm command fails or if

the show system firmware command shows that the SHMM firmware has

not been upgraded successfully, issue the system upgrade firmware

shmm command again.

43739 The system upgrade commit command might fail occasionally. In some

cases, the command returns an error, while in other cases, the command is

accepted but the show system upgrade command shows that the commit

has failed. Traffic is not affected.

Workaround: Issue the system upgrade commit command again.



Issue Description

40004 FPSD is disabled during a software upgrade. Therefore, if a condition

causing FPSD to turn off the laser occurs prior to a software upgrade, the

laser will remain off until both of the following occur:

FPSD is re-enabled after the upgrade completes

the condition causing FPSD to turn off the laser has lifted

Workaround: If this is an issue that you want to avoid, disable FPSD on the

interface before performing a software upgrade.

38728 A warm reboot of a UFM while provisioning changes are being committed

may cause an Equipment Degrade (eqptDgrd) alarm.

Workaround: If this occurs, perform a cold reboot of the UFM. To prevent

this problem from occurring, wait 30 seconds after the provisioning changes

have been committed and services are back up before performing a warm

reboot of a UFM.

38713 CLI auto-completion is not supported when specifying the target ports in the

WPS4 protection wavelength switch command.

Workaround: Specify the target ports manually.

37980 During commissioning, the following error sometimes appears: BTI CMM Commissioning Shell exiting as failed to read

fru_info.ini file

Workaround: If this occurs, unseat both CMMs and then re-seat both

CMMs.

37441 The BTI7800-EQUIPMENT-MIB contains extra TEXTUAL-CONVENTION

definitions. See Appendix A for details.

Workaround: These definitions are not needed and can be ignored.

34529 If an Equipment Degrade (eqptDgrd) alarm is raised against a BIC, no new provisioning can be applied to any other component on the same UFM as long as the alarm is in effect.

Workaround: Disable and re-enable the alarmed BIC to clear the alarm. This is service-affecting.

33164 The DCM time delay is not updated on the AMP after the DCM’s PEC is changed.

Workaround: Perform a warm reload of the AMP after changing the DCM.

33163 The DCM time delay is not reset on the AMP after DCM equipment is removed from it.

Workaround: Perform a warm reload of the AMP after de-provisioning the DCM.

32908 When both CMMs (or the single CMM in a single-CMM system) are restarted or re-seated, the show equipment command may temporarily indicate that no equipment is present. This condition occurs for approximately 30 seconds within the first 6 minutes of the CMMs restarting.

Workaround: Use the show inventory command to see the equipment. To verify that there are no issues with the equipment, use the show conditions command and verify that there are no equipment missing alarms.



Issue Description

32806 The 10GE interface does not return a Remote Fault (RF) when it detects a Local Fault (LF).

Workaround: None. However, compliant end devices will return a Remote Fault (RF) so all upstream devices will see the failure.

32511 In a multi-chassis system, pulling a CMM module from the hub chassis and pulling its attached counterpart from the satellite chassis may cause the other CMM on the satellite chassis to restart.

Workaround: Wait a minimum of 10 seconds after pulling a CMM module before pulling the other.

32146 In a system with two CMMs, upgrades should only be performed if both CMMs are operationally up.

30507 When using a Spirent or IXIA test set to conduct tests over a 10GE interface with the BTI7800, the BTI7800 may occasionally report a RF.

Workaround: Use the equivalent test sets from JDSU or EXFO.



5 Related Documentation

For more information on the BTI7800, refer to these publications:

■ BTI7800 Series Command Line Reference Guide

■ BTI7800 Series Hardware Overview and Installation Guide

■ BTI7800 Series Software Configuration Guide

■ BTI7800 Series Alarm and Troubleshooting Guide

· 2017-10-17 · the documentation. 45245 a bic sometimes shuts down autonomously due to a false...

Documents