Outstanding Issues - Avaya ERS 8600 Manual

Ethernet routing switch
Table of Contents

Advertisement

Disabling and re-enabling the IST session on an IST switch pair with VRRP configured between them will no
longer result in both switches reporting VRRP master ownership. (Q02104773)
Outstanding Issues  
Please refer to the Outstanding Issues Section of the Release Notes for Ethernet Routing Switch 8600 Software Release
5.1.0.0. Additionally, the following issues have also been classified outstanding issues.
Repeated HA-CPU failovers may result in R-modules going offline. It is recommended to not 'force' repeated
HA-CPU failovers. (Q02053766)
Upgrade of the software from 4.1.x to 5.1.2.0 has been reported to result in configured OSPF Md5 keys being
corrupted. For this situation, users with MD5 keys configured on OSPF adjacencies should reconfigure the
MD5 keys after the upgrade if this issue is encountered. (Q02127996)
With the smlt-on-single-CP feature enabled, 8632TXE ports are not taken offline when both the Master CPU
and Slave CPU are pulled out. (Q02123052)
IP Multicast packets of type PGM-SPM will get dropped when the multicast sender and the receiver are
connected to the same ERS 8600. At this time such designs to pass this type of traffic require the sender and
receiver to be connected to different ERS 8600s. (Q02119454)
In a triangular SLT setup with VLACP enabled only on the core boxes, if the ERS 8600 is rebooted, the SLT
port is not properly taken offline despite VLACP making the ports offline. Such a configuration is not
recommended as VLACP should be enabled on both core and edge connected devices. (Q02119095)
For a tagged R or RS module ports, the ERS 8600 will not properly honor the QoS marking of incoming
packets that need to also be copied to CP, i.e. network control packets. These packets will instead be sent to
the default queue setting for the port. This situation only has the potential to create operational issues for
situations where the CP utilization is already high. (Q02131463)
ERS 8600 may experience system instability when certain types of vulnerability scans, are run against it. It is
suggested that any vulnerability scans be tested first against a lab switch prior to those scans being performed
against production usage switches. (Q02110359)
In ERS8600, links on both R or RS modules currently remain up for 60 seconds after the primary SF/CPU is
removed in a non HA mode. Removing the primary SF/CPU is a non-supported action. User should first either
boot, reset, or force a switchover to secondary, before removal of the primary SF/CPU. Under these approved
mechanism the improper 60 second status will not be seen. This operation will be improved in a future release.
Q02102654)
Intermittently after several card-pull actions, I/O modules and the CP may lose communication and line cards
may be restarted by the CP. This operation will be improved in a future release. Repeated card pull/insert
operation is not a recommended activity; if performed, the slot should be disabled first. (Q02091483)
In HA-CPU environments, when master CPU card is pulled out and re-inserted, some line cards may lose
communication with the master CPU and may have to be re-inserted. Physical removal of the master SF/CPU
is not a recommended or supported action. A switchover to secondary CPU is recommended to be performed
first. (Q02128408)
System instability has been reported infrequently during handling of OSPF updates. Analysis of the system
data related to this issue indicates a strong correlation to the infrequent memory corruption addressed under
Q02093533 and Q02106560. A similar intermittent instability has been reported within SNMP which is also
currently believed to be linked to the memory corruption addressed in 5.1.2.0. (Q02125441, Q02118856)
Use pursuant to the terms of your signed agreement or Avaya policy.
Avaya Inc. – Proprietary & Confidential.
38

Hide quick links:

Advertisement

Table of Contents
loading

Table of Contents