Avaya has released software 6.1.6 for the Ethernet Routing Switch 5500/5600 series switches.
The following issues have been resolved with this software release;
- The dhcp-relay agent changed the MAC destination address of acknowledgments from a unicast address to a multicast address (wi00835598).
- After a reboot, some client ports with active connections would autonegotiate to a lower speed (10/100) than expected (1000).This issue affected some Intel 82556 and Broadcom NICs (wi00555121).
I’ve personally seen issue wi00555121 above while working with a large HP MAS (Medical Archive Solution) implementation. I also believe that someone (either on this blog or in the discussion forums) also brought up issue wi00835598.
The new feature includes VLACP enhancements with support for DOWN and HOLD subtypes which were introduced in 220.127.116.11 software for the Ethernet Routing Switch 8600. The goal of the new VLACP subtypes it to provide a means to allow the core ample time to get up to speed before the edge starts forwarding traffic. I’ve personally seen many an occasion where one Ethernet Routing Switch 8600 in a cluster goes down with minimal packet loss but upon recovery there are all sorts of packet loss and network interruption. This new feature is designed to mitigate that problem by allowing link to come up… VLACP to come active but hold the actual network traffic back until the core is ready to start bridging/routing packets.
VLACP Enhancements – support for DOWN and HOLD subtypes
The VLACP implementation prior to this release did not detect a unidirectional communication outage. A VLACP partner will now send VLACP PDUs with the subtype DOWN (value of 2) when no PDUs are received from its link partner. These PDUs indicate the remote VLACP partner is down and the link partner should logically bring down its port. Shortly after reboot, a VLACP partner will send PDUs with the subtype HOLD (value of 3) to its link partner. In this case, receiving a PDU with subtype HOLD indicates the VLACP partner should logically bring down its port for a VLACP hold time. When receiving VLACP PDUs with HOLD or DOWN subtypes, the VLACP partner will respond with normal PDUs (LACP subtype). The interval between PDUs is configurable by the user. The VLACP support for HOLD subtype is disabled by default, it will be enabled only when a positive value for VLACP HOLD Time is configured. VLACP is an Avaya proprietary protocol and hence this enhancement will not work when connecting to devices from other vendors.
You’ll recall from the Ethernet Routing Switch 8600 18.104.22.168 release notes that Avaya introduce a new VLACP subtype on the core side;
VLACP HOLD Enhancement
During SMLT node failure scenarios, traffic loss may be observed in certain scaled SMLT configurations with hundreds of SLTs, hundreds of ports and tens of VLANs. The root cause for the traffic loss was that the ERS8600 ports would come up prematurely at the physical layer causing the remote end to start sending traffic toward the ERS8600 that just came up. On the ERS8600 that just rebooted, the communication between the line cards and the CP may take several seconds in such scaled configurations. This resulted in black-holing the traffic arriving on such ports which were physically up but all operational configuration was not yet performed on those ports by the CP. The VLACP SUBTYPE HOLD feature introduces a new VLACP PDU with a new subtype HOLD to help reduce traffic loss in such scenarios.
The goal of this new implementation is to “hold down” all VLACP enabled links for a specific period of time after a reboot. This prevents remote VLACP enabled devices that understand the new VLACP HOLD PDU from sending data to the ERS8600. This will ensure that all VLACP enabled ports on the ERS8600 have had sufficient time to come up with all operational configuration and are ready to receive and forward the ingress traffic.
ERS8600 switches with 22.214.171.124 release are capable of both sending and receiving VLACP HOLD PDUs. Future code revisions of the Baystack switch family will support receipt and processing of VLACP HOLD PDUs, but will not generate them. Please refer to the applicable product release notes for information regarding product specific software levels required for support of this VLACP enhancement. VLACP is an Avaya proprietary protocol and hence this enhancement in not applicable when connecting to switches from other vendors.
By default, the VLACP HOLD feature will be disabled. The feature is enabled by configuring a positive value for VLACP HOLD Time. The VLACP Hold Time value configured should be selected based on the specific recovery implementation requirements, size and recovery characteristics for your network implementation.
You can find the release notes here. (I’m going to try linking to Avaya’s support website instead of hosting the files myself).
Lord Edam says
I’ve seen the autonegotiation problem with Checkpoint power-1 appliances. Our support company wouldn’t log it with Avaya and just told us to fix everything to gig/full – “there are always interoperability problems, you should always do this if you want to connect to a different vendor’s kit”, apparently.
Michael McNamara says
I’ve seen issues with Check Point UTM-1 appliances (1050, 2050) regarding auto-negotiation… there was a hotfix from Check Point that addressed the problem on SecurePlatform (operating system run on the UTM-1 appliances).
You can fallback to hard setting the speed/duplex as you mentioned but I usually like to exhaust all other means before taking that approach.
Thanks for the comment!
I had the autonegotiation issue waaaay back when and opened a ticket. At that time the song-and-dance I was given is that it was a timing problem between the Intel card chipset (which is where I was having a problem with some of my desktops and a few servers w/o the Broadcom chipset) and the 5520 Broadcom chipset.
And it wasn’t going to be fixed.
And they closed the ticket.
Michael McNamara says
Unfortunately Nortel support (was prior to the acquisition by Avaya) also told me essentially the same.
Ok, I tried upgrading from 6.1.4 to 6.1.6 and I promptly blew up my switch to the point it kept rebooting with a Data Access Execption error.
Which required me to go in and clear the flash (along with the configuration) and reconfigure.
At 6 pm on Friday night. Before spring break.
Anyone else having issues? Have opened a ticket but considering many of my switches are 500-600 miles away from me, I’m just a bit leery of upgrading to 6.1.6 at this time.
Michael McNamara says
I’ve been working through upgrading all our Ethernet Routing Switches 5000 Series (usually ERS5520s) upgrading them from 5.1.4 to 6.1.5. I haven’t deployed 6.1.6 yet although I generally try any upgrades out in our testlab and even after that I carefully select the first few sites just in case there’s a problem.
I’ll let you know (in this thread) once I’ve completed my testing of 6.1.6… right now I’m sticking with 6.1.5 as it’s tried and true for me.
I’ve seen this data access exception error! The stack keeps rebooting and support keeps sending RMAs.
Michael McNamara says
As mentioned by Curtis you can probably just clear the configuration and save yourself the RMA (assuming the problem is not with the physical hardware).
Hello to everybody
we need to upgrade our 5600 in a customer because it solves the dhcp relay pb
anybody has trouble also with upgrade , or a “murphy’s law” issue ??
we had tremendous pb upgrading another customer from 6.1.4 to 6.2.0 (had to redo full configuration with IST , SMLT and so on , took 1 hour per stack :-(
and have been told by support no to upgrade to 6.2.1 and wait for 6.2.2
any advice apprediated regarding upgrade from 6.1.4 to 6.1.6
thanks in advace
Michael McNamara says
I’m currently using 6.1.4 as a standard within my organization and I have yet to experience any significant issues. I will comment that I’m only using the about 5% of the switches as Layer 3 devices, the remaining 95% are just configured as simply Layer 2 switches. Are you sure which software release resolves the DHCP relay problem you mention?
I would suggest you visit the discussion forums, there’s a lot of great information over there.
i just have installed today a stack of 2 5650 which were delivered with 6.2.0 and i did downgrade it to 6.1.6 without problems (been told by customer to do so because he uses JDM and ESM …)
we added the stack to an existing SPLIT-MLT network with 2 chassis 8600 and all went smoothly
regarding DHCP issue , it is documented in 6.1.6 release notes :
The dhcp-relay agent changed the MAC destination address of acknowledgments from a unicast address to a multicast address (wi00835598).
thanks for your reply
Regards , PJ