Nortel has released software 3.7.4 for the Ethernet Switch 460 and Ethernet Switch 470. You’ll probably recall that Nortel pulled the 3.7.3 software release in May 2009 after several software memory leaks were discovered.
I should point out that you can’t just load 3.7.4 software if you are running software older than 3.5.4. You must upgrade the software in steps. Here’s the different versions that you need to step through; 2.x to 2.5 to 3.0 to 3.2.1 to 3.5.4 to 3.7.4.
Also of interest in the release notes is a comment regarding VLACP;
VLACP operation has been changed to match implementation on ERS modular and other stackable platforms with the latest software releases. A link for which VLACP is configured will remain in a blocked state until partnership is correctly formed with the VLACP partner (Q01799355).
I’m not sure what difference they are referring to… the wording makes it sound as though VLACP would initial start in forwarding mode and would only block the port once the timeout and retries had reached the configured threshold. I might need to dig a little deeper just out of curiosity.
You can find the release notes here.
I think this refers to the fact that, with older software versions, you could turn on VLACP at the edge and not lose connectivity before it was turned on at the core/distribution layer. I know with the 4500 series, once you turn it on at the edge, traffic stops till VLACP is up downstream as well. My guess is this is what will happen now with the 470s and 3.7.4
Hi Jeremy,
I believe your correct. I think the major change is that VLACP will immediately mark the port as down when it’s initially enabled both at the port and globally. The software won’t wait the retry time (500ms X 5 retries = 2.5 seconds) before declaring the port down as it did in the past. I have yet to test this but I believe this might have been the change they referenced. I’ve also noticed strange behavior if you enable VLACP at the port but forget to enable it globally.
Thanks for the comment!
There’s another possible VLACP change that this could be referencing–I haven’t verified this yet–it has to do with the MAC address utilized by VLACP.
In 5xxx pre-v5.1 and in 45xx pre 5.2 (I think this is where the change took place, so I’d encourage double-checking) the same mcast MAC address was recommended for use at VLACP global and at VLACP port level. This is, I’m almost certain, true for the 470 pre-v3.7.4
I’d guess that 470s at v3.7.4 will now behave like the 5xxx @ v5.1+ and 45xx @ v5.2+ : the recommended mcast MAC is now valid only for the global VLACP parameter. At the VLACP port level, the previously recommended mcast MAC is no longer permitted. You may, optionally, leave the port level MAC at all zeros or configure a unicast MAC. If you choose to leave it at all zeros, VLACP will establish a partnership with any other VLACP -enabled device at the far end of that port’s connection.
If you choose to configure a MAC address, it must match the system MAC of the VLACP -enabled device at the far end of that port’s connection in order for a partnership to be established. That means that if you have to replace the far end device, the near end port’s VLACP MAC address MUST be changed to reflect the new MAC of the far end device.