Update Friday April 16, 2010: The software is now available on the Nortel/Avaya support website. I’ve also posted a copy of the updated release notes, ERS8600_5_1_2_0_01.02_Release_Notes.pdf
Avaya has released v5.1.2.0 software for the Ethernet Routing Switch 8600. I know there were quite a few users waiting for this release. Please feel free to post back here to let us all know how your making out with 5.1.2.0 if you happen to deploy it.
You can find a copy of the release notes here but you’ll obviously need to visit the Avaya/Nortel site to download the software.
Here are some of the bullet points from the release notes;
Switch management
- The SNMP trap for rcIpBgpPeerLastError will now be sent with a proper byte string length such that the last bye will no longer be lost. This could previously cause operational issues with some SNMP management stations. (Q02092718)
- ERS 8600 will no longer observe system instability associated with configuration changes to switch parameters involving SNMP settings. (Q02094258)
- Previously the ERS 8600 was applying a local Access Policy to IPv6 routed SSH packets. Now the system will route these packets and apply Access Policies to only local destination policy type (SSH, Telnet, HTTP) IPv6 packets. This will no longer cause inappropriate connection issues to remote hosts. (Q02070640-01)
- ERS8600 has been modified to now allow proper communication with NetQOS Management Device. (Q02049612-01)
Platform
- With both filtering and ingress mirroring enabled on the ERS8600, system instability could be seen under certain traffic conditions. This is now resolved. (Q02078239-01)
- For non-routed VLANs, SLPP will now use a source MAC address equal to the Base Mac Address of the ERS8600 plus the ID of the VLAN. This will ensure that received SLPP packets are processed against the correct non-routed VLAN when a loop is present in the network and avoid erroneous warning messages. (Q02081719)
- IP fix traffic from the switch to an external collector will no longer be sent with an improper QoS marking of QOS=7, but instead sent with QOS=0, now placing these packets into the proper default egress queue. Previously this traffic could potentially interfere with other system management traffic leading to the potential for system instability when IPFix was enabled. (Q02044640-01)
- High CPU utilization on an I/O line card co-processor will no longer result in a loss of messaging synchronization with the SSF CPU, which previously could have led to system instability. (Q02085085)
- ERS 8600 will no longer show instability in tLogger task while writing to the PCMCIA card with clilogging enabled. (Q02006689-01)
- ERS 8600 R and RS module card ports will now initialize multicast and broadcast bandwidth limiting values properly when these features are enabled. (Q02074960)
- ERS 8600 will now properly handle any broadcast destination MAC IPX packets of type RIP or SAP. Previously this could cause and issue for routing IPX for E/M modules (R/RS modules do not support IPX Routing). (Q01997486-04)
- Packet throughput performance for jumbo frames at line rate has been improved for the 8612XLRS modules. (Q02075673)
- Filter pattern definitions for HTTP packet streams will no longer impact other protocol traffic. (Q02089688)
- Users will now be able to connect to an ERS 8600 using Secure Copy (SCP) with access-level rwa when access-strict true is also configured. Previously SSH worked, but SCP did not. (Q01767930-01)
- ERS 8600 will no longer encounter link flapping upon reboot of an OM1400 edge device running SFFD when connected to 8630GBR ports. (02014236-01)
- ERS8600 will now properly forward DHCP packets with the DHCP-relay agent configured as the VRRP virtual IP when the DHCP request has the broadcast flag set. Best practice recommendation still continues to be to configure the DHCP-relay agent IP address as the VLAN physical address and not the VRRP IP address. (Q02059607-01)
- Reliability of R and RS series line card recovery after CPU resets (normally seen during switch software upgrades) has been improved due to enhancements in SSF CPU to I/O module co-processor message communication and synchronization. (Q02091485/ Q01997485)
- ERS 8600 will no longer silently drop packets when the number of ACEs with debug count enabled is such that system resources are at their maximum, but instead the filters will now all function properly. (Q02045086)
RSTP/MSTP
- Enhanced MSTP/RSTP logging information which was previously added in release 4.1.3.0 was not present in any 5.x code. This functionality has now been properly added. Q02053232)
- The VLAN interface on an ERS8600 in RSTP/MSTP mode will no longer be brought up unless a port first becomes active in the VLAN. This matches the existing VLAN interface behavior in STP mode. (Q02083039)
- Packet loss on an MLT with RSTP enabled will no longer been seen after a CPU reset/switchover with HA mode enabled or after a complete switch re-boot. (Q02003158-01)
- ERS 8600 will properly retain the MLT path-cost configuration over reboots when configured for RSTP/MSTP mode. (Q02048253)
- ERS8600 will now properly show the MSTP CIST port pathcost info when “show port info mstp” is executed. (Q02048252)
IP Unicast
- The configured filter action is now properly observed for ACL’s configured to match UDP source and destination port ranges between 32752 and 32767. (Q02076252-01)
Static Routes
- ERS 8600 will no longer encounter system (DRAM) memory exhaustion with DHCP-relay configured on a Layer 2 VLAN or at the port level for a non-brouter port. (Q02076879)
BGP
- ERS 8600 will now properly learn the default routes from eBGP peers even after the failover or toggling of the physical port connection. (Q02094999)
IP Multicast
- ERS 8600 will no longer observe periods of sustained high CPU utilization associated with the forwarding of multicast traffic. (Q02067852)
- ERS 8600 will now properly recover its DVMRP status for an ATM interface when a Port/Fiber Fault occurs, and is then restored. (Q02041428)
MLT / SMLT
- Connectivity to NLB servers single homed to one ERS8600 in an IST pair will now function properly for SMLT connected devices when using an nlb-mode of unicast or with arp multicast-mac-flooding enabled. Configurations using nlb-mode of multicast were not affected. (Q02037778-01)
- SLPP will now disable the correct SMLT port when a loop is detected on an SMLT link where the smlt-id configured is not the same as the mlt-id value configured. (Q02089994)
- On ERS8600, FDB and ARP entries will point correctly to SMLT after IST peer reboots. Previously entries learnt on SMLT ports could very occasionally point incorrectly to the IST. (Q02091486)
RSMLT
- With ICMP redirect enabled on RSMLT peer switches, packets destined to the RSMLT-peer’s MAC address will now be forwarded correctly and not dropped as ICMP-redirect packets. (Q02091034)
- In RSMLT environments, ERS8600 will no longer add the RSMLT-peer’s MAC address to its Router MAC table. This will result in packets destined to the IP interface of RSMLT-peer to forward properly. (Q02091350)
VLACP
- ERS 8600 will now always bring down a port via VLACP within the configured timeout value when its VLACP peer goes down. Previously one end of the link would take an extra timeout cycle before downing the port in some scenarios. (Q02088710)
- In scenarios where a port was taken down by VLACP and then the far end switch is rebooted or VLACP recovered to recover the port, Persistent VLACP port flapping will no longer occur. (Q02088709)
- On E-mode enabled switches in full mesh SMLT topologies, protocol traffic will now flow properly on the second MLT link when the first MLT link is disabled. (Q02089615)
VRRP
- 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 mastership. (Q02104773)
Cheers!
Edson says
We faced a big problem (broadcast storm/high cpu utilization) that was caused by this issue:
ERS8600 will now properly forward DHCP packets with the DHCP-relay agent configured as the VRRP virtual IP when the DHCP request has the broadcast flag set. Best practice recommendation still continues to be to configure the DHCP-relay agent IP address as the VLAN physical address and not the VRRP IP address. (Q02059607-01)
Can´t believe it was solved!!
Michael McNamara says
I’m happy to hear that they were able to resolve the problem.
Curtis says
Did 5.1.2.0 get pulled back off the website? It doesn’t appear in the list of available 8600 software versions and if I go through the Release Notes and select it, I am getting an “Invalid Software Link” message.
Michael McNamara says
Hi Curtis,
I found out today that 5.1.2.0 software is in Controlled Availability (CA) meaning that it’s not generally available just yet. I suspect the product management folks are just being careful in vetting the current software release before allowing it into the wild.
I’ve been told that the code should be GA by mid March 2010.
Cheers!
Curtis says
Found out the same thing yesterday from our Nortel…oops, Avaya SE.
Adam Dacosta says
Great post! I have shared it with our community with a link to your post.
Thanks, great stuff!
AD
Michael McNamara says
Thanks for the kind words Adam!
Mark Starry says
So, Michael as the ultimate Nortel/Avaya ninja… ;-) Yes or no to 5.1.2.0 We are experiencing many of the annoying bug fixes, but nothing critical. Our network has to be platinum (99.99% availability), but we still have to manage it and the IPFIX bug is huge to us.
Thanks!
Mark
Michael McNamara says
Hi Mark,
Well as of right now 5.1.2.0 is not yet available. Here’s my recommendation for folks, depending on hardware and feature sets. If you are just looking to stabilize your ERS8600 IST/SMLT configuration then 4.1.8.3 is a good stop. If you want/need 5.x software then 5.0.5 seems very stable and reliable. If you want to live on the edge 5.1.1.1 has been good for me but there are reported issues with RIP routing and RS modules.
– 4.1.8.3
– 5.0.5.0
– 5.1.1.1
Those are the options today and I would recommend and that I am using in my production network. You MUST read the release notes. It’s highly recommended to read the release notes of all interim versions that you’ll be skipping if you jump from say 4.1.4.0 to 4.1.8.3. There’s a lot of useful information in the release notes that generally doesn’t get captured anywhere else and usually gets lost.
Unless you’re really suffering you might want to hold out for the 5.1.2.0 software release.
If you are using VRRP you MUST have unique VRRP ID throughout each switch… if you don’t your switch will tank once you upgrade.
Hopefully that helps!