Hello, when MST convergence occurs in the topology, are the ports configured as Spanning-Tree Edge Trunk impacted by the changes in the topology, i get these logs :
Here is the text with the asterisks removed from the start and end of each line:
sw-core2-d2 %ETH_PORT_CHANNEL-5-PORT_DOWN: port-channel35: Ethernet1/35 is down
sw-core2-d2 %ETH_PORT_CHANNEL-5-FOP_CHANGED: port-channel35: first operational port changed from Ethernet1/35 to none
sw-core2-d2 %ETHPORT-5-IF_DOWN_PORT_CHANNEL_MEMBERS_DOWN: Interface port-channel35 is down (No operational members)
sw-core2-d2 %ETHPORT-5-IF_DOWN_INITIALIZING: Interface Ethernet1/35 is down (Initializing)
sw-core2-d2 %ETHPORT-5-IF_DOWN_PORT_CHANNEL_MEMBERS_DOWN: Interface port-channel35 is down (No operational members)
sw-core2-d2 %ETHPORT-5-IF_DOWN_PORT_CHANNEL_MEMBERS_DOWN: Interface port-channel35 is down (No operational members)
sw-core2-d2 %ETHPORT-5-IF_DUPLEX: Interface port-channel35, operational duplex mode changed to Full
sw-core2-d2 %ETHPORT-5-IF_RX_FLOW_CONTROL: Interface port-channel35, operational Receive Flow Control state changed to off
sw-core2-d2 %ETHPORT-5-IF_TX_FLOW_CONTROL: Interface port-channel35, operational Transmit Flow Control state changed to off
sw-core2-d2 %ETHPORT-5-SPEED: Interface port-channel35, operational speed changed to 10 Gbps
sw-core2-d2 %ETH_PORT_CHANNEL-4-PORT_INDIVIDUAL: port Ethernet1/35 is operationally individual
sw-core2-d2 %ETHPORT-5-IF_UP: Interface Ethernet1/35 is up in mode trunk
From the syslog messages you have shared, it seems that the topology change is due to the fact that the Ethernet1/35 port went down, and the port channel had no more operational members, meaning no more forwarding members. The result is the portchannel as a logical interface went down too.
Edge trunk ports by definition are configured to skip the spanning-tree listening and learning phases so that they can transition directly to the forwarding state. Thus, edge trunk ports should not directly participate in STP convergence. However, they can be affected indirectly if their upstream or downstream links experience a topology change, or if the underlying physical link goes down, as in the example you shared.
Hello Laz,
Thank you for your feedback. These ports are connected to VMware vSwitches.
The links are connected and have not physically gone down. The logs shared were presented after the MST convergence, and the ports are down. I would like to understand the reason for this.
Thanks
Taking a closer look at the logs I see that the portchannel went down and then came back up. Because I don’t see timestamps in the logs, I am assuming that the downtime was momentary, on the order of a second or two.
There are a couple of reasons why you may see these temporary downtimes occur when MST converges:
If a trunk is configured as an edge trunk if it receives a BPDU, it will disable the portfast feature and reenter the STP process as a regular spanning-tree trunk. If the convergence caused the portchannel which is configured as an edge trunk to receive a BPDU, this may result in what you see in the syslogs. After this event, does the port remain configured as an Edge Trunk port or has it lost its status?
Another possibility is that the MST reconvergence may cause a disruption in the LACP operation. For example,
If the port lost its status as an edge port, and MST transitions the port out of forwarding (e.g., into blocking or learning), the switch may stop sending/receiving LACP PDUs on that interface or classify it as “individual (as seen in the syslogs).
Because LACP sees the port as not actively participating (no PDUs, or forced into a blocking state), it removes the interface from the active bundle. This removal is often logged as “port-channel X is down (No operational members)” or “port is operationally individual.”
Once MST completes reconvergence and moves the port to forwarding, the physical switch and its peer begin exchanging LACP PDUs again. The port then rejoins the channel, resulting in up/down/up logs in quick succession.
All of the above are just thoughts and suggestions that may help you in your troubleshooting process. Let us know if this has sparked any insight, and if you have performed further troubleshooting steps so we can help you further if needed.