EtherChannel - implementing over 802.1Q tunneling
When implementing EtherChannel over a service provider network using 802.1q tunneling, it is important to remember to map each individual physical link of the port channel to a different VLAN within the provider's network.
Refer to the following topology: The goal here 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. (The VLAN IDs can be any value.)
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
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.