I tried labbing this up in VIRL as well and it does indeed work as expected. So it seems you have confirmed a bug in GNS3 when using this particular configuration and IOS versions.
In your configuration, you’ve used the desirable keyword which means you have enabled PAgP unconditionally. Have you tried implementing a manually enabled port-channel using the on keyword? Also, have you tried making the ether-channel an access port instead? It would be interesting to see if the bug occurs just for trunk and PAgP configuration or if it persists even if you change these…
If you do end up configuring them, let us know your results!
Hi Lazaros,
Yes I tried with the 3 modes (Lacp, PAgp, manual) with the same results.
Also, I tried with the physical links and Port-channel link as access links with the same output, and with only the port-channel as access + physical links as trunks but the links cannot bundle and stay in suspended state (in show etherchannel summary command).
Very weird indeed !!!
Thanks for sharing your results and being so thorough! It looks like it’s confirmed, there is a bug… It happens occasionally with GNS3, but I believe that through this process of testing various configurations you gained a better understanding of EtherChannel!
Hi Lazaros,
Glad to read that I discovered a bug !!!
Yes it made me practice and to be definitely certain of what was going on, I labbed it this morning with real devices (2 switches (catalyst 3750) and 2 pcs) and played a bit around load balancing, stp cost, interface packets rates and so on.
Pity to see that my GNS3 environment is buggy but now, indeed I know how things work.
Thank you for your time and help
There are many use cases for creating EtherChannel links that function as trunks. You’ll often find EtherChannel used within datacenters where increased bandwidth between switches is required. You will also see it in the distribution and core layers of the three-tier model of network design. In both of these cases you will find that the EtherChannel link you create will be a trunk to accommodate the many VLANs that exist in these areas of the network.
It’s an easy and free way to increase bandwidth between devices, by simply leveraging otherwise unused physical ports. EtherChannel exists in almost all of the networks I’ve provisioned, especially as you get closer to the core and data center portions of the network.
escuse me but may ask sth. Trying to test, configure , change the instructions given according to this tut. i was not able to make it work. According to the documentaion cisco
mentions that does not support etherrchannel. Also i think there are things not mentioned in this tutorial. Could u please clarify the exact procedure in order to test it. For example SW1 has not join vlan 100. Thnx
I tried to reproduce the configuration of this lab in Cisco CML and I was able to do it successfully. Can you share with us a little bit more about the trouble you’re having?
Just to clarify, the Cisco documentation you shared indicates that EtherChannel is not supported on the interfaces configured with the QinQ tunnel. Specifically, using the topology in the lesson, it means that you cannot configure Etherchannel between SW2 and SW3 and configure QinQ on that link. It does not restrict the implementation of EtherChannel between SW1 and SW4.
VLANs 100 and 200 are the service provider VLANs carrying the traffic. These VLANs don’t appear on SW1 and SW4. The VLANs on SW1 and SW4 are set to the default VLAN 1 in the lesson, but can be anything. These do not affect the configuration of the QinQ feature.
For more about the QinQ feature, take a look at this lesson.
HI ,SW1 is a Customer wants to talk to SW4 .Y we need to use separate VLAN (100,200) in Fa0/23 and in fa0/24 instead can we use single vlan say 100 ?
if Fa0/23 and fa0/24 talk to each other then what s the issue ?since SW1 is a single customer rt …All traffice belongs to same Cu (SW1)…If they talk to each other whats s the problem? please advise me on this
The goal of the exercise is to make SW1 and SW2 think that they’re directly connected and that they have created an EtherChannel bundle between them. SW2 and SW3 which belong to the ISP appear to be “transparent” to the customer switches.
In order to make this work, we must create a transit VLAN within the ISP infrastructure for every physical link of the EtherChannel. In this case, we have two physical links, so we need two transit VLANs, specifically VLANs 100 and 200.
Why? Well, we want to make sure that:
traffic that exits Fa0/23 on SW1 enters Fa0/23 on SW4.
traffic that exits Fa0/24 on SW1 enters Fa0/24 on SW4
traffic that exits Fa0/23 on SW4 enters Fa0/23 on SW1.
traffic that exits Fa0/24 on SW4 enters Fa0/24 on SW1
Now in the lesson, Rene states that:
If we use a single transit VLAN for all traffic on the FastEthernet 0/23 and 24 interfaces, then we run into issues with our Etherchannel because FastEthernet 0/23 could talk to 0/24 or vice versa.
What he is saying essentially is that if we don’t segregate the traffic from each individual physical link onto a separate transit VLAN, traffic that arrives at the switch may enter from either port. Such an arrangement would cause EtherChannel to fail. Does that make sense?
