Thanks. Is that just a time saver? If I confgure it on the member interfaces doe that cause a problem? (double encapsulation?)

The reason I ask is because I tried to set up an etherchannel bundle between two switches between two buildings. The two member ports that connect the two sites ride different transport. One is 100Mb microwave and the other is comcast tls (100Mb). With both connections configured in the bundle I can get the etherchannel running but only if I set the mode to "on". In this situation when I look at spanning tree I see all vlans in FWD on one member port and on the other, the vlans alternate between FWD and BLK. Because I am weighting priority in an alternating fashion so I would not expect to see this.

The port channel does alternate between FWD and BLK.

If I shut a member port down on one side, the whole bundle drops until I pull the corresponding member port on the other side.

The member ports plug in to a device at either end before going TLS/wireless so my first thought was that PAgP was relying on link state but a quick search tells me it's done with keepalives.

Desirable-desirable will not bring up the bundle, only one pair of member ports.

bouncing this connection showed that there is no consistency in which member pair ends up in all vlans FWDing and whuch ends up in alternating FWD BLK state.

A couple of questions:

Why cant I use anything but mode ON/ON?

Why do I have to shut down the corresponding member to get the link up?

Are the keeplalives broadcast/multicast?

Are they encapsulated?

I'm stumped and couldnt get much out of TAC on this. They looked at the config and said it looked good. I need to schedule an outage to work on this so I need to gather these details or find the solution before trying again.

Thanks

It probably only works in on mode because something is different in the setup on each end . In order to use a negotiated etherchannel both ends must be configured exactly the same and with the same type and speed transports. If the etherchannel is actually working I wouldn't expect to see any in a blocking state as spanning tree across a etherchannel group is considered a single spanning tree for each vlan so it would not have a loop built in across that etherchannel. To me it sounds like the channel is not actually working but you are trunking across across 2 separate connections. If you do a "show etherchannel summary on both sides does it look like its working correctly?

We checked the config on each member interface and they are all the same. We did have to disable flow control on one interface to get the etherchannel up in on-on mode.

In on-on mode the etherchannel summary shows the etherchannel established. In desirable-desirable, one member port shows master not in bundle.

The really strange part is that we have to shut down corresponding member ports for the bundle to fail over to the other member pair. Shutting down one interface should do that...