%Jan 25 05:05:58:071 2023 HPE-5945-Core-HGO LAGG/6/LAGG_INACTIVE_OPERSTATE: Member port WGE2/2/1 of aggregation group BAGG601 changed to the inactive state, because the peer port did not have the Synchronization flag.
Hi, I have the same problem: 2 switches directly connected to the "core switch", when a loop occur in in one of them, in the other the lacp goes down :-(
Original Message:Sent: 1/26/2023 7:02:00 AMFrom: cdiasSubject: RE: Spanning-Tree ProblemsHi,On my previous post I already sent the configuration on the remote switch and on the Core switch it connects to.What happens is that it shutsdown the BAGG and also the physical interfaces for 30 seconds.We found this was caused by another switch connected to the Core that was not running lacp but has redundancy by spanning tree. One of the links to core was flappping and for some reason it impacted on the lacp switch, wich is strange.RegardsOriginal Message:Sent: Jan 26, 2023 05:21 AMFrom: Davide PolettoSubject: Spanning-Tree ProblemsHi!"spanning tree should not be a issue"Technically speaking STP is not an issue but a helping mechanism...so in a loop-free network a properly configured Spanning Tree topology is perfectly stable and help you to keep your network free of loops (physical member interfaces of a properly configured and working BAGG, from the STP standpoint, can't generate a loop in the interconnection between peer switches...at least if the involved BAGG are working correctly)."And the the loop-protection shuts down the port for 30 seconds."What port? a BAGG is a Logical Interface, are you referring to a physical member interface which is part of a BAGG or what?Can you show us the STP configurations running on the Core Switch and on a sample Distribution/Access Switch and the status of involved BAGGs?Are you sure there aren't loop at access level (on Edge interfaces)? is your network topology physically loop-free (considering the relationships between the Core and each Distribution/Access switch)?Original Message:Sent: Jan 25, 2023 06:32 AMFrom: cdiasSubject: Spanning-Tree ProblemsHi,I have several switches that connect to the Core using LACP links, so spanning tree should not be a issue.The configuration is like this on the switchinterface Bridge-Aggregation601description Ligacao ao Core - Bastidor 1port link-type trunkport trunk permit vlan alllink-aggregation mode dynamiclink-aggregation lacp traffic-redirect-notification enablestp loop-protectionAnd on the Core is:interface Bridge-Aggregation601description Bastidor 1 (Datacenter)port link-type trunkport trunk permit vlan alllink-aggregation mode dynamicstp root-protectionSince a few days I get messages like:%Jan 24 22:42:09:914 2023 SW2_8 LPDT/4/LPDT_VLAN_LOOPED: A loop was detected on Bridge-Aggregation608 in VLAN 400.%Jan 24 22:34:08:181 2023 SW2_8 LPDT/5/LPDT_VLAN_RECOVERED: A loop was removed on Bridge-Aggregation608 in VLAN 250.%Jan 24 22:34:08:179 2023 SW2_8 LPDT/4/LPDT_VLAN_LOOPED: A loop was detected on Bridge-Aggregation608 in VLAN 250.%Jan 24 22:28:12:242 2023 SW2_8 LPDT/5/LPDT_VLAN_RECOVERED: A loop was removed on Bridge-Aggregation608 in VLAN 900.And the the loop-protection shuts down the port for 30 seconds.My question is how can I have a loop reported if I do not have stp redundant links, but lacp instead?Also sometimes I also get the message:
This happens in several switchesThanks
I have the same problem discribed on this post and I still do not understans the cause.
I have a single LACP link with two phisical ports, connecting to the Core.
Both the core and the remote switch are a IRF, so each physical port connects to a different switch on the other side.
I have loop-detection configured on the LACP, but how can a loop exist, since there is only the LACP link between the switches?
How can it report a loop?
Hi, I think the most important fact is that when the message says it is detected on BAGG608, that does not mean the loop is on that interface. If you have a LACP between two IRF pairs, and beyond that you have other switches, the loop could be downstream. The loop detect frame is transmitted over the LACP link, continues somehow more hops before looping back to the source. The loop detection frame should be discarded by switches downstream but we see times when that doesn't happen. Perhaps a different switch OS or a really basic switch.
Put loop detect on all ports of all switches and follow the loop hop by hop until you get a message that it is on an edge port. Typically I only see it on one of the two looped edge ports, which ever detects the loop first.
The only other way I can see this happening legitimately is of one side of the LACP considers the physical ports to not be in a LACP. For example if you add the wrong physicals to the BAGG on one side.
If you have loop detection on all ports and vlans on the downstream switch, and LACP is correct, but nothing detected, that would be a support case.
Thanks for you answer.
We are using loop-protection on uplinks, because that was a suggestion o Support after some problems with loops some years ago.
There should be no physical loops on the network, unless someone causes them, because the uplinks to the core use LACP of two ports.
So once again clarify please:
It makes no sense to configure loop protection on uplinks, correct?
On the edge ports we configure:
loopback-detection enable vlan 1 to 4094
loopback-detection action shutdown
And on uplinks we configure:
Any of this configurations is wrong?
Carlos Dias Technical Consultant
© Copyright 2023 Hewlett Packard Enterprise Development LPAll Rights Reserved.