I'm currently on Chapter 4 of Odom's book, on page 108 it mentions a list of interface settings that are checked such as speed, duplex, etc. these settings apart from STP settings are also supposed to match on the neighbour in order for the Etherchannel to be operational, I've tested using different allowed VLAN list on each side of a trunk link to see if the Etherchannel goes down, but it still seems to work, I've tried with manual configuration on each side and using PAGp, and, it still works fine.
Is the information in the book incorrect or is there any other reason that this sill works?
I tested this on real gear not on a simulator.
That was a good spot.
Hower this is working as intended.
It's working because the configuration of all the physical ports in the bundle is compatible. Meaning - all the configuration of the ports that are making the bundle is actually configured with correct parameters to be able to form a port-channel.
When that's done...and you get your port-channel up, you can still have a logical mismatch between allowed vlans at both ends of the trunk - just as you could with any physical interface!
Etherchannels doesn't require the "allowed vlans" to match at both ends of the trunk to work. Or rather - a trunk port doesn't require that the allowed VLAN's match at each end of the trunk. It will still trunk, all the VLAN's that is allowed. As a matter of fact...this is a very common configuration mistake with trunk-ports.
All the physical layer parameters must match to be able to be part of a port-channel interface.
Don't forget that once you configure your port-channel interface, the configuration on each physical interface in the bundle is inherited down from the virtual port-channel interface. So once you apply some "allowed vlans" on the virtual port-channel interface, it will be the same on the other interfaces in the bundle.
That's why as a general best practice is to configure etherchannels in the following order:
For layer 2 - put the physical interfaces in the port-channel/channel-group then configure the port-channel interface and the configuration will be inherited by the physical interfaces
For Layer 3 - very important! First configure the physical interfaces with "no switchport" THEN add them to the channel-group THEN configure the port-channel interface. Otherwise the channel-group will be considered a Layer 2 interface and can't be re-configured into a layer 3 interface!
So bottom line...as long as you remember to bundle them first and then do the configuration on the port-channel interface, all the physical interfaces will have the same configuration as the port-channel interface. After that - it's just working as one logical interface with the same requirements that a physical interface would have.
The requirements to be able to bundle ports are called compatibly charecteristics:
-Configure all ports in an EtherChannel to operate at the same speeds and duplex modes.
-Enable all ports in an EtherChannel. A port in an EtherChannel that is disabled by using the shutdown interface configuration command is treated as a link failure, and its traffic is transferred to one of the remaining ports in the EtherChannel.
-When a group is first created, all ports follow the parameters set for the first port to be added to the group. If you change the configuration of one of these parameters, you must also make the changes to all ports in the group:
–Spanning-tree Port Fast setting
And as my final note.....the spanning-tree port cost does NOT need to match to form a port-channel! Even with PAgP or LAcP!
Hope that helps you in understanding why it works - if not, just shout out and i'll clarify !
Hi again Michael,
I think you are bending the worst a bit -but yes, depending on what operational means You are correct and the book is wrong. If you look at the quote:
I'm currently on Chapter 4 of Odom's book, on page 108 it mentions a list of interface settings that are checked such as speed, duplex, etc. these settings apart from STP settings are also supposed to match on the neighbour in order for the Etherchannel to be operational,
It's possible to interpret those words in two ways:
-Operational = Up/Up (as in working to forward traffic)
-Operational = Up/Up AND working as intended. (allowed vlans mismatch on the trunk-configuration is probably not working as intended)
Personally for me to consider a Trunk-port to be operational...it means that you can forward traffic on it. It doesn't mean that it's correctly configured for your network.
So I agree with you that if that's how you interpret "operational" then the book is incorrect.
It's very rare to see errors like that in any Odom-book. Have you checked the errata to see if it's been corrected?
In either case ... yes .... the compatibly check is just local to the switch where you create the port-channel interface.
Once your port-channel interface is created, it's a logical interface.
Connecting two logical interfaces together as a trunk-port will mean that if you want to configure them as a trunk-port, the trunk-port will work as long as you follow the trunk-rules.
There is no rule that says the allowed-vlans list needs to match, it just tells your switch which vlans are allowed to use that interface and place a 802.1Q tag on the frames crossing it.
Sorry for reviving an old post, but this place feels the most appropriate place to write this
I am also in the same point in the book as OP mentions and have come the same issue. While I understand and agree with what Daniel says, my issue is with example 4.3 presented in the book (on the same page as OP mentions) as it leaves little room for interpretation. See below for a small excerpt:
I have been unable to reproduce this example in any way. Iv'e spent close to a day trying out various configurations of etherchannel and STP using a Catalyst 3750E (IOS 15) and VIRL L2 (IOS 15.2) images in GNS3. Moreover, the only way I am aware of to fire the "channel-misconfig (STP) error detected on ..." protection is to have multiple BPDU's arriving over the various links in an etherchannel with different source MACs, hence the STP involvement in the error message (see this post for a better description Reg. Etherchannel guard).
When following the steps identified in the excerpt, I observed the following. I set STP cost different on each link, then configure the channel-group commands (tried with different modes) the link comes up without issue and ignoring the STP costs. The STP cost can then be set on the etherchannel directly if needed. In general the STP cost will be completely ignored from the constituent links, e.g. if I set them both to 10 then create the etherchannel it will calculated the STP cost based on the speed of the links.
While many of the other situations mentioned in the book will result in the etherchannel not operating as desired, usually with either suspending a link or marking the port as broken in STP. The STP cost does not appear to be a valid example, and I struggle to understand why it was explicitly included in the book.
Ive checked the books errata, but it makes no mention of this. So I was wondering if anyone could help enlighten me? Is this perhaps older/newer IOS version that behaves in the way identified in the book or some additional configuration that is needed?