Nortel has released software 6.0.5 for the Nortel Ethernet Routing Switch 5000 series switches.
Here’s the list of added features;
- Total system uptime in days since first power up
- Support for DDI SFPs
- Improved 802.1AB detection to work with Avaya Ip Handsets (Q02109202)
- Shared port enhancement
Here’s the list of bug fixes;
- Radius Accounting Configuration is not saved after upgrade (Q01995703).
- ERS55xx/6.0.3-keeps sending re-authentication when radius VLAN Assignment NEAP (Q01994731)
- Static routes getting disabled, after link to next hop is broken (Q02002640)
- 8 sec impact on traffic through base unit when non-base is reset (Q01997338) –
- SLPP packets loop over 55xx MLT ports during VLACP link flap on the BS (Q01926412-01)
- Port Names Are Missing When Upgrading From 184.108.40.206 to 220.127.116.11 (Q02019044)
- Auth Status not properly returned in JDM/SNMP for Port Security (Q02011169-01)
- Running Security scans by using Qualys tools caused switch crashes (Q02004709-01)
- RSTP MLT ports seen as forwarding but actually blocking (Q02011420-01)
- Data Exception type: Data Access Task Name “tIdt” (Q02024889)
- EAPoL is properly functional only when Radius server is reachable with ICMP (Q02025072)
- The switch is not relaying DHCP larger than 590 byte (Q02042427-03)
- Some Layer-2 packets are not properly forwarded (Q02032738-01)
- Intermittent traffic loss over DMLT connections to 8600 (Q02045069-02)
- IfAdminStatus and IfOperStatus Show Interface As Being Down (Q02073525)
- 5520 6.0.2 Transmit BPDUs After STP Is Disabled Causing MLT Port Blocking (Q02082301)
- VLAN creation causes switch to wedge (repeatable) (Q02039074)
- Filter on Multicast Traffic drops OSPF control traffic (Q02103672)
- Switch Locks Up When OSPF Interface Is Brought Up (Q02075419-01)
- Certain DHCP clients don’t have an entry in the binding table (Q02084318-01)
- Switch failed to respond to DoS attack (Q02009674-01)
- Re-booting edge switch triggers SLPP loop on core switch uplink port (Q02045991)
I believe the issue below was reported by a few readers and perhaps even in the discussion forums. In any case the release notes offer two workarounds and suggest the problem is not evident in 6.1.2 software.
With SMLT configured, the default route was learned on an incorrect port after core stack reboot (Q02123318)
Is issue is only partially fixed in 6.0.5, not reproducible with 6.1.2. There are two workarounds:
– clear the arp-cache
– Configure VLACP on the IST ports.
As always I would strongly suggest you review the release notes for yourself.