It’s great to see Nortel putting out these technical documents.

Cheers!

I encourage everyone to review the following guide which our team of senior solution architects maintain to ensure you achieve the highest level of availability. https://support.nortel.com/go/main.jsp?cscat=DOCDETAIL&id=948343&poid=9015

I would also recommend to pay attention to the Converged Campus Solutions guides. There is now both a large and small campus versions posted to Nortel web, and a medium one will be posted soon. These all provide best practices recommendations which will ensure you get the best experience in using this key differentiating Nortel feature set.

Richard McGovern
ERS 8600 PLM, Nortel

I didn’t say that VLACP et IST/SMLT are not good technologies, I just said they are “spoiled” by bad implementation and annoying bugs.

On VLACP long timers, we had to use them because short timers where incompatible with HA-mode on the 8600 (at least until 4.1.4.0) ! VLACP went crazy on CPU switch over (as all sub-second protocols) :-(

I agree with you : the latest 8600 code is really great, and now HA-mode works flawlessly on unicast traffic.

I’m now working on multicast traffic, and I can say that there’s still a lot of work to do on multicast and HA-mode !

Thanks for the link to the forum, there’s not much Nortel user forum on the Internet !

I’ll have to disagree with you and say that VLACP is a great tool to have when designing highly available and redundant networks. You obviously need to understand how VLACP works and how to configure it properly to take full advantage of the features it offers. VLACP is designed to be a very lightweight protocol to provide highly available networks for VoIP. The key here is “lightweight”. Nortel didn’t require you to upgrade the switch fabric, CPU, or chassis when they delivered this feature so the designers need to be conscious of the load they place on the CPUs and modules. Unless you have a design requirement for using long timers (IST links) you should use short times (recommended values are short timers at 500ms with 5 retries ~ 2.5 seconds).

With regard to your test… VLACP operated just as configured… you configured it with long timers (20 seconds) so it would take 20 seconds for it to detect a missed VLACP heartbeat, then depending on the number of retries you have configured it could take 20 seconds * retries to ultimately mark the port as VLACP down.

If you had any doubt about the future of SMLT/IST you only need look at Cisco’s new vPC technology. While Spanning Tree and Rapid Spanning Tree were/are great legacy protocols there so much to be said about running a Spanning Tree free topology.

I personally think the software feature set on the ERS 8600 is quite impressive and has really matured greatly over the past two years. While Nortel has definitely had it challenges (ERS 8600 software release 4.1.6.x still put chills down my spine) the last few software releases have been very stable and have provided additional value to the legacy hardware that’s already installed.

Thanks for the comment! Please feel free to make additional posts over at the forums; http://forums.networkinfrastructure.info/nortel-ethernet-switching/

Cheers!

I still haven’t understand why the switch should compute the mean time between VLACP packets… The developpers didn’t notice that there were timers used by the protocol ?

Despite being really simple, VLACP is badly coded and doesn’t work properly between different equipement series (eg 5510 and 8600).

The main bug I’ve found (still not solved) is this one : VLACP / LACP is supposed to work like TCP three-way handshake or OSPF hello protocol.
Data should normally be flooded on the link after the handshake is done, when both switches have seen each other and (V)LACP is up.

Sadly, this is not the case with VLACP.
Try the following between a 8600 and a 5510 : setup a MLT with 2 links on which VLACP is activated, and use slow timers (set up at 20s).
Plug the 1st link, MLT should become up and data should flow correctly between the 2 switches.
Plug the 2nd link, and you’ll observe a 20s packet loss : the 5510 waits 20s before sending any VLACP packet, but the 8600 doesn’t wait and starts flooding data just after sending its first VLACP packet. Result : the 5510 drops all received packets during 20s.

Solution from Nortel : use short timers, which reduces the loss at 500ms. Thanks…

The more I work with SMLT/IST, the more I prefer RSTP.
It’s sad to see such good hardware and such bad software :-(

Release notes are here:

http://support.nortel.com/go/main.jsp?cscat=DOCDETAIL&id=828529&poid=18122

The solution for this situation is to either 1) set VLACP timer values to 500 msec time-out with scale of 5, or 2) wait for 6.0.3.x code on 5530. This same situation applies to other stackable products, which is also detailed in the Bulletin.