The BIG lab – Part 1 – Trunking, EtherChannel and Load-Balancing

I kind of feel that I really need to spend more time on my studies at the moment. So while the boys are down for their afternoon nap (but not sleeping) it’s a good chance to get some EtherChannel work done.

In the real lab, there will be a fairly large selection of switches and routers, and although you will have a number of specific tasks to complete both for the troubleshooting portion and the configuration portion it’s important to understand that one task can greatly impact on another.

So instead of having little posts concentrating on one particular topic I have decided to make a number of posts but all sharing the same topology so that the impact of one design decision can be shown throughout the network.

So let’s have a look at the things that I want to cover, and start building our topology.

Starting at the top of the CCIE exam topics we can cover:

Now you will have to excuse my drawing skills, I am using a Wacom Bamboo tablet and still getting used to it, but I think we’ll end up with something like this:

So we have a number of routing protocols, a bit of frame relay, some trunking, EtherChannel, well throw in some dial-up technology, tunneling and some IPv6 as well, and let’s throw in some VTP for good measure. I think that this series will be very organic and will change and grow as we progress.

Let’s start creating the netmap, as always I start by numbering the devices from left to right. and working out the connections from there. Apart from getting the R10 to SW1 interfaces round the wrong way, once I corrected it I ended up with this:

Cisco IOU netmap

If you are interested, the netmap looks like this:

1:0/0 2:0/0
2:0/1 3:0/0
2:0/2 4:0/0
4:0/1 5:0/0
5:0/1 6:0/0
6:0/1 7:0/1
4:0/2 8:0/0
5:0/2 9:0/0
8:0/1 9:0/1
8:0/2 10:1/0
10:0/1 11:1/1
11:0/0 12:0/0
11:0/1 12:0/1
11:0/2 13:1/0
13:0/0 14:0/0
13:0/1 14:0/1
12:1/0 14:1/0

So let’s start at the top of our list and work our way down. I might just cover some trunking today as the kids have not gone to sleep, but they did get up at 8:30 this morning instead of their usual 7am, so it’s not surprising really.

Switch basic configuration

Let’s start by setting up a VTP domain and have the switches as either a master or a client, along with some different VLANs. If the switches support it we might even get to do some HSRP, but I am not sure if they do. To be honest, I don’t even know if they do EtherChannel, but I guess we’ll find out whether this is a limitation of the software (IOU) or not.

Trunking – VTP and 802.1Q trunks

We’ll start by creating a bunch of VLANs on SW1, and set up VTP.

So in SW1 we set up a bunch of VLANs, (10,20,30, and 40 using the “vlan 10” etc command), and then set the vtp mode to server (which is the default but I still like to know that I have set it manually), and set the domain from null to 802101:

VTP Server setup cisco switch

Now we can set up a trunk to SW3, we will only use 802.1Q for our trunks because the other trunking protocol (ISL) isn’t used much anymore.

We aren’t going to do anything fancy with our trunk (at least not yet) so its a basic configuration:

802.1Q trunking on a Cisco Switch

And I have set SW3 as a VTP client for the 802101 domain:

Cisco switch vtp client

Usually its worth heading back to the server to make an amendment to the VLAN database on the server to force it to send the updates to the clients. So I added VLAN 50 on to SW1, and then running “sh vtp status” on SW3 I can see that the two are talking:

cisco vtp status

OK, so thats the link between SW1 and three done. Lets set up SW2 and 4 in the same way:

setting up vtp client and trunking

setting up vtp client and trunking

Now we can set up our EtherChannel links between SW1 and SW2 (PAgP) and between SW3 and SW4 (LACP).

EtherChannel – Setting up PAgP and LACP

I said earlier that I wasn’t going to bother with ISL for our trunks because it’s no longer used much, well the same does not hold true for the EtherChannel protocols. Both are used and both have a very good chance of being included in the exam. Therefore I will be doing both. PAgP (Port Aggregation Protocol) is the Cisco standard, whilst LACP is the industry standard.

For any type of EtherChannel to work the settings on the interfaces within the port-channel group must match identically, so you can’t mix duplex or speed for example. I prefer to set mine up using the interface range command (“interface range ethernet 0/0 – 1”). First I shut down the interfaces (you don’t have to, I just like to know I have got everything set before I try and bring the port-channel up), then set them up as trunks, adding them to the port-channel group 1. I have set SW1 as “auto” for PAgP:

pagp etherchannel cisco

and SW2 as “desirable” for PAgP:

setting up vtp client and trunking

Lastly, I did a “no shut” on the interfaces.

The basic config is:

SW(config)#interface range ethernet 0/0 - 1
SW(config-if-range)#switchport trunk encapsulation dot1q
SW(config-if-range)#switchport mode trunk
SW(config-if-range)#channel-protocol <protocol>
SW(config-if-range)#channel-group 1 mode <mode>
SW(config-if-range)#no shut

Let’s have a look at the last two lines in a bit more detail.

We start by setting the protocol, this is either PAgP or LACP:

cisco etherchannel

And then we set the mode

cisco etherchannel channel group mode

Both sides could have been made desirable for PAgP, or active for LACP, and would have formed a channel-group, but if both were set to auto (PAgP) or passive (LACP) then no channel-group would form, as neither would be actively seeking to make a channel-group.

Here is a sh run from both sides:

port channels and load balancing

port channels and load balancing

And as if by magic if we do a “sh vlan” on SW2 we can see that by the magic of VTP we have our VLANs now:

vtp in action

Now let’s turn our attention to SW3 and SW4.

There isn’t much different between the setups, the same commands have been used to create the trunk links:

port channels and load balancing

port channels and load balancing

And lastly on SW4 we check to see if our VLANs are all present and correct:

vtp over port channel
And they are.

From now on our port-channel operates pretty much just like any normal interface, We can do a “sh int po 1” and see the following:

show port channel

The interesting thing here is that we can see the members of the port-channel (in the last line).

We can also check on our neighbor switches:

port channels and load balancing neighbor


I did set up src-dst-mac load balancing on SW1 and SW2, it is a global statement


I chose src-dst-mac


Load balancing is pretty simple really.

And that about covers it for today. The boys didn’t sleep at all this afternoon, so now it’s half past eight at night and its time for a snack.

Next up we’ll cover the PPP link between R1 and R2.