Comware

%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.

%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.

%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.

%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.

%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.

Original Message:
Sent: 1/26/2023 7:02:00 AM
From: cdias
Subject: RE: Spanning-Tree Problems

Hi,

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.

Regards
Original Message:
Sent: Jan 26, 2023 05:21 AM
From: Davide Poletto
Subject: Spanning-Tree Problems

Hi!

"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 AM
From: cdias
Subject: Spanning-Tree Problems

Hi,

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 switch

interface Bridge-Aggregation601
description Ligacao ao Core - Bastidor 1
port link-type trunk
port trunk permit vlan all
link-aggregation mode dynamic
link-aggregation lacp traffic-redirect-notification enable
stp loop-protection

And on the Core is:

interface Bridge-Aggregation601
description Bastidor 1 (Datacenter)
port link-type trunk
port trunk permit vlan all
link-aggregation mode dynamic
stp root-protection

Since 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:

%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.

This happens in several switches

Thanks

%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.

%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.

%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.

%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 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?

Please advise

%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 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. 

Hi,

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?

Please advise

%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 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. 

Hi,

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?

Please advise

%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 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. 

Hi,

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?

Please advise

%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.