EtherChannel over 802.1Q Tunneling

Hi Rene,

But, if you assign a specific customer vlan just for one link, doesn’t that defeat the purpose of building the etherchannel i.o.w to have a redundancy when one link in the channel goes down ?

Hi Edwin,

Yes, in this example there’s still only one link between SW2 and SW3. I’ve only added this example since it’s a topic on the CCIE R&S blueprint.

Rene

Rene,

Is there is a pdf file for all of these topics?

Hi Koundinya,

I’m afraid not, right we only offer our content online.

Hi Rene,

Now the Etherchannel is formed across the Switch 1 and Switch 4, is it the trunk link, suppose i have Vlan 10,20,30,40 on Switch 1, so once etherchannel is formed, all this Vlan will pass through it?? without any extra configuration on Service provider Network??

Does this link also send VTP message?? can we also make Switch 1 as Vtp server and Switch 4 as VTP client, and after that If we create New Vlan on switch 1 for example Vlan50, will this Vlan will pass over Etherchannel to Switch 4 since switch 4 is VTP client.

Hi Rene,
I recently viewed Q in Q tunneling for Etherchannel, and i have below query, please advise.

Now the Etherchannel is formed across the Switch 1 and Switch 4, is it the trunk link, suppose i have Vlan 10,20,30,40 on Switch 1, so once etherchannel is formed, all this Vlan will pass through it?? without any extra configuration on Service provider Network??

Does this link also send VTP message?? can we also make Switch 1 as Vtp server and Switch 4 as VTP client, and after that If we create New Vlan on switch 1 for example Vlan50, will this Vlan will pass over Etherchannel to Switch 4 since switch 4 is VTP client.

Hi Rupesh,

Once the Etherchannel is formed, all VLAN traffic from SW1 and SW4 should pass yes. We are using Q-in-Q tunneling so it should work.

You can make VTP work by adding l2protocol-tunnel vtp. You can also do this for CDP and STP.

Rene

Hi Rene and thank you for the lessons,
I tried to reproduce this lesson on GNS3 and everything works fine BUT what I’d like to understand is how can the traffic continues to flow through the etherchannel link (vlan 100,200) when one of the link goes down ? I tried a ping from a PC behind SW1 (192.16.1.1) to a PC behind SW4 (192.168.1.2) and it’s okay but when I shut down a physical link from the etherchannel, it seems the traffic can’t go back because it doesn’t come from the same vlan as previously, can you
guide me for this case please?
Thank you

Hello Frederic

It seems that when you configure Etherchannel on the link between the service provider equipment and the customer equipment, you can only configure each link to carry a single VLAN. This means that you will require the same number of physical links as VLANs that you want to share across the QinQ tunnel. Etherchannel will not provide redundancy for other VLANs if a physical link fails in this scenario. This is further supported by this Cisco documentation that describes how to configure this:

So the behaviour you see where one of the VLANs fails when the link corresponding to that VLAN is disconnected is expected.

I hope this has been helpful!

Laz

Hi Lazaros and thank you for answering,

So, if I understood correctly, my only vlan 1 is only distributed through the same outgress and ingress port (g0/1 on CE in my case, by the way how that port is chosen ? With a kind of STP priority port ? )

So in that case, what is the purpose and benefit to establish an etherchannel from CE to PE (only affect each vlan on a different physical link ? This sounds not really scalable if you have many vlans)

Can you hep me clarify this point please ?

Thank you for your help

Hello Frederic

You’re right in the fact that this doesn’t look like a scalable solution. Restricting one VLAN per physical link is also not very flexible. What if you want to add another VLAN? Well, the truth is you can’t.

This feature is actually what I would call a “best effort scenario” of trying to make one technology work with another. It’s the best that can be done. So if you are using QinQ through a service provider to send your VLANs, and you absolutely need to create port-channel links between your own switches and those of the service provider, then this is the only way to achieve this. It’s cumbersome, but it works, under the right conditions.

Remember that SW1 and SW4 must be oblivious to any intervening infrastructure. So SW2 and SW3 have to “trick” these switches into thinking that they are directly connected so that their Etherchannel PAgP negotiation will function. Unfortunately, this is the only way to do it.

I hope this has been helpful!

Laz

Hello Lazaros, once again thanks a lot for helping me to understand those concepts.

I understood. My mistake was to tunnel pagp but to mount the etherchannel with mode on !!!

What I tried so, is to put PCs in 2 different vlan (PC1 & 3 in Vlan 1 : 192.168.1.X, and PC2 & 4 in Vlan 2 : 192.168.2.x) on each side of the network : everything is okay : PC1 pings PC3 and PC2 pings PC4.
What is struggling me is how the port-channel “choose” which vlan will be carried out on each physical link, is there a kind of priority or is it possible, via the load balancing concept, that each packet are crossing one of the 2 physical links independently (one packet on a link, the next one on the other ?) because when I shutdown one of the link both of my continuous ping fail (continuous pings from PC1 to PC3 and PC2 to PC4).

Have a nice day

EDIT : after a wiresharck capture, it seems that both my continuous pings are carried out via the only int g0/1 (corresponding to the one with vlan 100 on the PE side), as if my second link (vlan 200 on PE) is never used…
I’m getting more and more confused about that…

Hello Frederic

That’s interesting… Actually that shouldn’t happen. When you shutdown one of the links, only the VLAN that is carried via that link should shutdown. Can you do a show etherchannel on one of the customer switches to see the state of the Etherchannel? That will give you an indication of why your packets are not getting through.

I hope this has been helpful!

Laz

HI,
I guess this is a GNS3 bug because, trying to understand what was going on, I built a simple scenario with 2 PCs, 2 switches, 1 vlan, 2 physical links in 1 ether-channel with no consideration about tunneling and, with a continuous ping from PC1 to PC2, the ping stops as soon as I shut down 1 link of the ether-channel; I tried with Pagp and Lacp and with auto as well with the same result…even if the ether-channel status is fine (I mean, the remote switch’s detection of the link failure is ok, except in auto mode where the links are still bundled), the ping never starts again, so I guess I should trust that idea that it should work, but does not in my GNS3 lab environment…very frustrating…
It’s weird…I’ll look about that to see if I can find a solution to be sure that my labs are okay…
If you have any info regarding that…
But anyway, I want to thank you for your help
Have a good day
Fred

Hello Frederic

This does seem like strange behaviour. It is indeed the case that the EtherChannel should revert to sending traffic over the other available links whenever a link goes down. I tried labbing it up myself and found that the ping does continue (after 1 or 2lost pings) once one physical link is shutdown. I suggest you try to recreate the lab topology found in the following lesson and verify your findings once again to see if you get the same behaviour.

If you do, please share your results here, and also specify the version of GNS3 you are using as well as the IOS images so that we have a record of the combination that results in this behaviour.

Thanks and we look forward to hearing about your findings!

I hope this has been helpful!

Laz

Hi Lazaros,
I tried once again to build a very simple topology with only an Etherchannel, I enclose the topology screen and the config below :

PC 1 : IP 192.168.1.1 255.255.255.0
PC 2 : IP 192.168.1.2 255.255.255.0

SW 1 & SW 2: default config except :

interface Port-channel1
 switchport trunk encapsulation dot1q
 switchport mode trunk
!
interface GigabitEthernet0/0
 switchport trunk encapsulation dot1q
 switchport mode trunk
 media-type rj45
 negotiation auto
 channel-group 1 mode desirable
!
interface GigabitEthernet0/1
 switchport trunk encapsulation dot1q
 switchport mode trunk
 media-type rj45
 negotiation auto
 channel-group 1 mode desirable
!
interface GigabitEthernet0/2
 shutdown 
 media-type rj45
 negotiation auto
!
interface GigabitEthernet0/3
 media-type rj45
 negotiation auto
!
interface GigabitEthernet1/0
 media-type rj45
 negotiation auto

Then I tried a continuous ping from PC1 to PC2 and then shutdown g0/0 on sw2, etherchannel status go like this :

on switch 2 :

SW2#sh etherchannel summary 
Flags:  D - down        P - bundled in port-channel
        I - stand-alone s - suspended
        H - Hot-standby (LACP only)
        R - Layer3      S - Layer2
        U - in use      N - not in use, no aggregation
        f - failed to allocate aggregator

        M - not in use, minimum links not met
        m - not in use, port not aggregated due to minimum links not met
        u - unsuitable for bundling
        w - waiting to be aggregated
        d - default port

        A - formed by Auto LAG


Number of channel-groups in use: 1
Number of aggregators:           1

Group  Port-channel  Protocol    Ports
------+-------------+-----------+-----------------------------------------------
1      Po1(SU)         PAgP      Gi0/0(D)    Gi0/1( P)  

And on SW1 :

SW1#sh etherch summary 
Flags:  D - down        P - bundled in port-channel
        I - stand-alone s - suspended
        H - Hot-standby (LACP only)
        R - Layer3      S - Layer2
        U - in use      N - not in use, no aggregation
        f - failed to allocate aggregator

        M - not in use, minimum links not met
        m - not in use, port not aggregated due to minimum links not met
        u - unsuitable for bundling
        w - waiting to be aggregated
        d - default port

        A - formed by Auto LAG


Number of channel-groups in use: 1
Number of aggregators:           1

Group  Port-channel  Protocol    Ports
------+-------------+-----------+-----------------------------------------------
1      Po1(SU)         PAgP      Gi0/0(I)    Gi0/1( P) 

It confirms that every traffic is delivered through g0/0 since the ping fails and never restarts.

I’m using GNS3 V2.2.14
My switches images are vios_l2-adventerprisek9-m.03.2017.qcow2 (but I tried with IOU as well : i86bi-linux-l2-adventerprisek9-15.2d.bin with the same results)

Thank you for helping.

EDIT : 11/19 : I tried the same topology on packet tracer and it works as expected so this is definitely a gns3 bug or something like that.

Hello Frederic

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!

I hope this has been helpful!

Laz

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 !!!

Regards

Hello Frederic

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!

I hope this has been helpful!

Laz

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

Regards
Fred
Ebverything is working as expected

1 Like