Hi Sarah and flokki123,
Please allow me to join, and I will go sequentially over individual statements in your posts.
Even if both sides of a bundle are configured with a PAgP mode of on
This is probably a misnomer. The mode on is neither PAgP nor LACP - it is none. No signalling is done between the two switches. The switch configured with on simply starts using the EtherChannel bundle right away without negotiating with the neighboring switch. Once again, with on, there is no PAgP nor LACP involved at all.
the redundancy of the link is compromised in the event of a failure on the link that is carrying spanning-tree traffic
Not really true Or better said, it is not that straightforward.
STP BPDUs are sent through the EtherChannel bundle as any other frames - their addressing field is processed by the load balancing algorithm to identify the particular egress port in the bundle, and subsequently, they are sent out using this single port. If this port is shut down or disconnected, the load balancing algorithm will simply choose some other egress port in the bundle. The delivery of BPDUs to the neighboring switch has therefore no reason to be compromised. This is what you saw yourself - you simply removed one link from the bundle and the STP BPDUs started being sent over the other link.
It is true that the BPDUs sent through this single port determine the entire STP role/state of the neighboring end of the bundle. After the neighboring switch processes the received BPDU, the result of its processing (determining whether the receiving port is eligible to become a new root/designated/alternate port) dictate the STP role/state for all ports bundled in the EtherChannel. Hence, if - for example - BPDU LoopGuard was activated on all ports in the EtherChannel, and the link carrying BPDUs would suddenly, for whatever reason, stop carrying them without going entirely down, the LoopGuard will block the entire EtherChannel, not just the "silenced" link.
So this is probably what the book tried to say: if STP running over an EtherChannel decides to perform an action, it is always going to act on the entire EtherChannel as a whole, not on individual member links.
the statement from your book mentions this behaviour with respect to PAgP.
So is it possible that you configured the channel with the command "channel-protocol lacp"?
and LACP might treat the STP traffic differently than the PAgP protocol.
Hmm, this should not make any difference whatsoever. PAgP and LACP are both only signalling protocols that allow switches to actively negotiate the EtherChannel before its actual activation takes place. However, they do not have any influence whatsoever how the packets are being load-balanced among the ports in the bundle - once the EtherChannel is established, its operation is always the same, be it PAgP, LACP or on.
In addition, it seems that the channel-protocol lacp command actually does nothing except disallowing you to use the channel-group mode desirable/auto/on as any of these commands would activate PAgP (desirable/auto) or run without any signalling protocol (on).
Best regards,
Peter
