Hi @MJB80 !
STP is not a pre-requisite for a link-aggregation and if your IRF stack has STP disabled, it won't stop it from forming an aggregation. Just use 'link-aggregation mode dynamic' in order to have LACP-assisted aggregation. This will protect your network from incorrect wiring and potential loops that may happen over a miswired link-aggregation.
If your Cisco swtiches use PVST+ or Rapid-PVST+ (in Cisco they love PVST, not sure why), maybe it's a good idea to enable it on the 5945 as well. Keep in mind your 5945 can speak that "lingo" too, just use 'stp mode pvst' in your 5945 IRF stack, so you are not limited to the standard MSTP (which will work fine too, but requires some planning to make PVST-MSTP interoperability trouble-free)
I just wanted to know that with STP disabled could an incorrectly configured LAGG between switches cause a loop?
In general if STP is disabled and a LAGG is static (no protocol) then incorrect LAGG configuration and wiring may cause loops.
However, if you use dynamic LAGG, then LACP protocol will try to protect you (as much as it can) from misconfiguration and miswiring.
However, since LACP doesn't really care about VLAN mapping of connected ports it's quite easy to have a situation when both switches use different PVIDs (native VLANs) on the LAGG. In this case broadcast and multicast traffic can 'leak' from one VLAN to another creating loop situation. However, if LLDP is enabled it's got by default a PVID Inconsistency check enabled (you can disable it with 'lldp ignore-pvid-inconsistency' if needed) so it's another layer of protection from misconfiguration.
There is one alternative for STP protocol - loop detection. The best thing about it is the fact it doesn't rely on adjacent device's support and compatibility, so you can enable it on the 5945 stack without changing anything in Cisco's config. And it doesn't require STP.
Here is what the guide says about it:
The device detects loops by sending detection frames and then checking whether these frames
return to any port on the device. If they do, the device considers that the port is on a looped link.
Loop detection usually works within a VLAN. If a detection frame is returned with a different VLAN
tag than it was sent out with, an inter-VLAN loop has occurred. To remove the loop, examine the
QinQ or VLAN mapping configuration for incorrect settings.
The protocol is pretty lightweight - frames are small and are being sent every 30 seconds in each VLAN where the loop detection is enabled, so it won't cause any additional load on your network.
Hi Matt!
Loopback-detection can be enabled globally or per port (BAGG as well).
The Layer 2 Configuration Guide https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US&docId=a00098726en_us (page 248) says:
You can enable loop detection globally or on a per-port basis. When a port receives a detection frame in any VLAN, the loop protection action is triggered on that port, regardless of whether loop detection is enabled on it.
So in order to enable it on a BAGG you need the following config:
system-view
interface Bridge-Aggregation1
loopback-detection enable vlan allThe default action of the loopback detection is just log message generation in case of a loop. Keep in mind that among 3 possible actions - 'block', 'no-learning' and 'shutdown' only 'shutdown' is supported on a BAGG. You can set the desired loopback detection action either globally or per port. Global action will affect all the ports where looopback-detection is activated. More details can be found in the abovementioned guide as well in the Layer 2 Command Reference Guide - https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US&docId=a00070972en_us
Hope this helps!