VSP9k, VSP8k, VSP7k SLPP design

[MarcD23]

Hi,

There are multiple 'best practice' Avaya design documents available in regards to switch clustering, however, the latest of these that I have found is from 2015. One issue we're hitting at the minute is the determining the current recommended best practice for deploying SLPP in an SMLT environment. The latest product documentation sets contain the following in regards to SLPP port thresholds -

Primary switch - 5
Secondary switch - 50

Avaya recommends that you configure the rxthreshold above 50 slpp packets only on lightly
loaded switches. If you configure the rxthreshold to a value greater than 50 on a heavily loaded switch and a loop occurs, the system can experience high CPU utilization.

which contradicts previous recommendations of multiples of the number of VLANs tagged on the port with a maximum of 500 (incredibly frustrating to keep tabs on in a large environment). It does also raise the question of how a 'lightly loaded' switch is measured.

My reason for raising is that during a network outage last year Extreme/Avaya advised on setting CP limit values to the recommended values in the product documentation which completely went against those that were the 'best practice' values on which the deployment was based.

Does anyone have any comments as to whether the product documents should now over rule the older best practice guides?

[Roger_Lapuh]

Yes, agree. We are working on "EVDs" (Extreme Validated Design documentation), we are planning on including best practice documentation there as well. But yes, we do also have to update our best practices guides in general. However our grand goal is it to apply best practices more automatically to reduce confusion and increase network stability. One example is that on newer releases Spanning Tree is automatically disabled on SPB-NNI links rather than just documenting it.

Roger

[MarcD23]

Hi Roger, thanks again for replying on this. Appreciate that CP limit and SLPP are 2 different things that was just so I could give an example of the difference of recommendations between documents.

I'm hoping that if Extreme continue with the VSP range that they will re-visit the best practice documentation as it was very helpful when deploying to customers. Appreciate that each network is different however having those best practice values in place gave a good foundation.

thanks again.

[Roger_Lapuh]

Marc, let me try to give you some perspective from my side here:
When we introduced SLPP we made it a per VLAN function, because we did see with SMLT that loops were accidentally created by users looping only certain vlans on tagged links and untagged traffic would not loop. In order to detect those loops, you can select on which VLANs you turn on SLPP. In order to avoid that both IST switches shut down their looping links isolating the edge, we provided the different time out values as a recommendation.
Now, if you have many VLANs running SLPP on a link, in case of a full loop, you get a lot of SLPP packets back. For that reasons some folks had increased the rx threshold above 5/10. This however delays the shut down, if only fewer slpp packets are received, thus making the CPU busier during the loop.Lightly loaded switch I would say means that constant CPU load is below 30%.
Now CP-Limit is another functionality. We had used this extensively on ERS8600/ERS8800, but not VOSS-VSP products. I believe ERS edge switches and the older VSP7000 supports it as well.
I think if you have SLPP configured on many VLANs on an SMLT pair, cp-limit could make sense, since it will trigger faster than SLPP with higher rx values. However, VOSS-VSP switches have much better CP queue handling compared to ERS8800, thus cp-limit is much less required.

Typically newer docs overwrite older docs, so I would use the younger guidance and also keep in mind that not all guidance can be applied the same way to all products due to capability differences.
I hope this helps.

Roger