Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

STP and PAgP Question

Hey Guys,

I understand that PAgP supports the following modes, [desirable, auto, and on] With Desirable PAgP PDUs are sent

via multicast MAC address 01-00-0c-cc-cc-cc. I understand that one auto is configured, it passively waits for PAgP

PDUs to negotiate the Etherchannel. I know with on, PAgP is runs, but no PAgP PDUs are sent back and force, and

it's basically forced.

So if I have port gi1/1/1, gi1/1/2, gi1/1/3, and gi1/1/4, between Switch-A and Switch-B, I also understand that STP will

be sent out the first operational port in the EtherChanel. So let's say that's gi1/1/1. If I choose the 'on' method with

PAgP, obviously no PAgP PDUs are sent. But let's say for some reason gi1/1/1 goes down(On Switch-B), if it's

configured as 'on' will it switch to send BPDUs down gi1/1/2 because if not, then from Switch-A's point of view, I

assume that port will be not-connected, and even though 3 other ports are up, STP will prevent them from being used.

I know PaGP in desirable and auto will prevent this.


STP and PAgP Question

  Not sure of your question but you are not supposed to use "on" mode with pagp or lacp it can detrimental effects.

Serious traffic problems can result from mixing  manual mode with PAgP or LACP modes, or with a port with no EtherChannel  configured. For example, if a port configured in on mode is connected to another port configured in desirable mode, or to a port not configured for EtherChannel, a bridge loop is  created and a broadcast storm can occur. If one end uses the on mode, the other end must also.

Hall of Fame Super Blue

STP and PAgP Question


I suspect i may be misunderstanding your question but etherchannels are point to point connections. If a port goes down then both ends of the link will remove it from the etherchannel and STP would simply use one of the other remaining ports to send BPDUs.

I am not sure how you are relating this to PAgP. Certainly a misconfigured etherchannel can potentially lead to a loop in the network as Glen says and there is an excellent thread on this where Peter Paluch goes into all the details but you are talking about both ends being configured as on as i understand it.

If i have misunderstood please clarify.


STP and PAgP Question


I was reading some documentation on PAgP, and it was talking about, possible loops with Spanning Tree. I might have just confused myself with what I was reading.....

I'm going to go search for that thread with Peter

STP and PAgP Question


I found that post, thanks for the heads up!!

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.

That's the part I was having some issues understanding. Paul explained it a whole lot better, than the documentation I previously read.