Avaya has released software v5.1.5.0 for the Ethernet Routing Switch 8600. It should be noted that Avaya has pulled software release 5.1.4.0 from their website. The release notes indicate that the reason for this was “an infrequent, but potentially service impacting timing interaction with auto-negotiation” on 1000BaseT ports on R and RS modules running 5.1.4.0 software.

Here are the resolved issues;

Platform

• An infrequent, but potentially service impacting timing interaction with auto-negotiation has been identified with 1000BaseT ports on R and RS modules running release 5.1.4.0. This issue may be encountered after link state transitions and could result in significant degradation of link throughput. There is no visible indication of this problem being present on the switch and is only detected through symptoms of link throughput degradation. This issue has been resolved in release 5.1.5.0.
• MGID exhaustion error messages were displayed in some conditions during Vlan port enable/disable. A logic error in validating MGID allocation during port enable and disable functions has now been corrected. (Wi00732528).
• A table synchronization issue between the master and slave CPU in HA mode has been corrected. Previously there was the potential for some QOS mapping configuration elements to not be sync.d between Master and Slave after HA Failover. (Wi00698375).
• If the rlogin flag is disabled on the system, new TCP connections could still be established (although not active) on the rlogin port. This issue is resolved by blocking TCP from accepting any new connections for rlogin port when the rlogin flag is disabled on the switch. (wi00837637).
• Following a switch reboot, TCP connections would previously be accepted on the HTTP port when the webserver is disabled on the switch. This issue is resolved by blocking TCP from accepting any new connections for http port when webserver is disabled. (wi00816539).
• In case of network running PIM, there is a possibility of memory corruption happening while processing the mroute list. This issue is resolved by ensuring the memory is accessed correctly. (Wi00508085, Wi00508269).
• The configuration command “config/bootconfig/net/mgmt# ip default” now properly sets the net mgmt IP to default ip address. (wi00730804).
• Performing an SNMP walk with XFP.s inserted into the switch would result in significant delay in SNMP response. This has been resolved through the implementation of a more efficient query of data elements for the XFP. (wi00518708).
• Since Rel 4.1, when a user defines filter redirection action, the availability of the next hop for the redirect was only validated at configuration time. Code changes have now been implemented to dynamically validate the redirect next hop’s availability at run time (WI00834842).
• Deleting a filter containing the action next-hop-redirect without first disabling the filter would no longer results in sending continuous ARP requests. (Wi00834842).
• A scenario was been identified where repeated Packet Memory Refresh events occurring on a specific card could lead to a system outage due exhaustion of the switch fabric memory (reported as “Fab Memory Full” errors). Diagnostic improvements have now been added to avoid the system outage which will take the card offline if 5 Packet Memory Refresh events are encountered within a 50 second window or 15 encountered within a 210 second window. (Wi00731139).

VRRP

• In a square SMLT setup, power-cycle of one VRRP backup node could result in VRRP state transitions in the other VRRP nodes during switch recovery. VRRP advertisements from the lower priority VRRP node are now properly handled in this scenario.(Wi00704114).

DHCP

• In 5.1.x release the number of DHCP Relay instances was reduced to 512. The number of configurable DHCP relay instances has now been increased to 1024 (Wi00716374).
• A DHCP relay agent reply handling failure scenario was identified in the 5.1.4.0 load which has now been addressed. Switches configured to provide DHCP relay agent capabilities with DHCP clients connected via S/MLT may experience hardware error logs indicating an invalid port reference: HW ERROR portGetPortNum: invalid physical port <portNumber>. On switches without an IST configured this error may also be associated with DHCP reply failures. (wi00852552)

IP Multicast

• In some routed ANYCAST topologies IP multicast traffic was impacted for up to 60 seconds when the primary path was removed due to deletion of the mroute entry. Handling of this scenario has now been corrected. Note that a alternate route must also be present in the alternate routing table in order to minimize routing convergence delay.(WI00564776, Wi00822532).
• MSDP error messages indicating “AS number not found” were seen if the route to the peer is learned through an IGP. In this scenario the local AS number is now used. (Wi00733871).
• In some scenarios, the IGMP querier was not set properly after receiving the query message. This issue has now been resolved.(Wi00730185).
• Multicast traffic was forwarded to CP in some conditions in an IST/SMLT condition. This scenario has been addressed by adding a missing discard entry when the source RPF check fails (Wi00747850).
• IGMP static entries did not work properly after CPU switchover with PIM-SSM. Sequencing interactions between IGMP and PIM-SSM configuration and event handling during CPU switchovers have now been addressed. (Wi00564255).
• An IGMP table corruption scenario has been addressed where the (S,G) entry was not properly updated when multicast source VLAN was taken down. (Wi00564227).

MLT / SMLT

• Fragmented TCP/UDP packets were not hashed through the same MLT link. Fragments with TCP/UDP port info were forwarded based on L4 hashing while the remaining fragments were forwarded based on L3 hashing. All TCP/UDP fragments in a fragmented datagram will now be forwarded based on L3 hashing (Wi00564807).
• An rare scenario was identified where an FDB mismatch was observed during MAC movement between 2 MLTs. A consistency check has now been added to prevent this scenario from occurring. (Wi00601530).
• In SMLT environments, the MAC entries in both the IST peers were previously marked as SMLT Remote TRUE when the IST synchronization occurred on an existing MAC address that had transitioned to a different port. This scenario now properly reflects which switch last updated the MAC address destination.. (Wi00686043).
• In SMLT environments, packets arriving on IST can be sent on SMLT links instead of being blocked. These scenarios have been addressed by discarding the packets from the IST with unknown srcMac, or the dstMac is learned through the same IST. (Wi00852559).

BGP/VRF

• Supermezz image loading failure would previously result in all the VRF VLANs being configured under the global router as the VRF configuration requires a mezz card and would not be activated. To avoid potential service impact, all I/O cards will now be taken offline and configuration loading blocked if configuration elements requiring the mezz card are present and the mezz card failed to load. The CPU will still boot up on the base CPU. (Wi00774936).

VLACP

• The “time-out” scale for VLACP protocol to bring the port down was miscalculated and taking twice the time of configured value. This issue has been rectified. (Wi00728743).
• The periodic timer interval for sending VLACP Hellos was miscalculated and taking twice the time of configured value. This issue has been rectified. (Wi00728749)

There was a significant outstanding issue (IMHO) that I should mention here;

• A potential packet handling issue has been identified specific to 8648GTR and 8648GTRS cards for configurations where an MLT port is defined on ports 41 through 48. In this scenario, an ingress packet that needs to be flooded within the VLAN could potentially be incorrectly forwarded back the other link in the MLT. This is a pre-existing issue and will be addressed in a future release. (wi00856177)

You should review the release notes for all the information!

Cheers!