Chapter 1 – Introduction
When we connect switches together, we need to think about things like… What happens if a link fails? And, do we have enough bandwidth between these switches?
To provide redundancy and increase bandwidth, we’re going to look to a technology called Etherchannels.
Chapter 2 – What are Etherchannels?
We’ve recently been talking about spanning-tree. What would spanning-tree do in a case like the one you see here? It would effectively block one link to prevent a loop right?
But we still would consider having two links here for redundancy. That is, if one link fails, the other one would take over. The second link is basically a backup in case the first one fails.
This is good, but not ideal.
Let’s say that these are both 1-Gig links. What happens if we have high levels of traffic? If there’s more than 1-Gig, the link wouldn’t be able to handle it, and some traffic would be dropped.
Does the second link help out? Nope. It’s blocked. It can’t do anything.
So we could upgrade the link, but that may be expensive. So let’s look at an alternative.
Etherchannel is a technology that takes two or more physical links, and bundles them into a single logical link.
So, back to our case where there’s two links between a switch. We could configure them as an Etherchannel, and they would act as a single link, with up to 2-Gig of bandwidth.
And because it appears as a single link, spanning-tree won’t block either link, so both can be active at once.
Also, if one physical link fails, the Etherchannel still works as normal. With diminished bandwidth of course. This means that spanning-tree doesn’t need to recalculate, or send TCNs, or anything like that.
As long as at least one physical link is up, the logical link stays up.
You can usually have up to 8 physical interfaces in an Etherchannel. Some switches allow you to go as high as 16.
Before moving on, there’s a couple of things I’d like to mention. Firstly, Etherchannel is a Cisco term. They also call it a ‘port channel’ or a ‘channel group’ as these are the commands we use in configuration.
Other vendors will use terms like LAG, or Link Aggregation Group, or perhaps AE, which is short for Aggregated Ethernet.
Despite the different names, these are all standards based. That means that you can configure an Etherchannel on a Cisco switch, and connect it to a LAG on another vendor’s switch.
We always have a few quiz questions through these videos, so here are a few to get you started.
Chapter 3 – Manual Etherchannels
Etherchannels can be configured manually or dynamically. We’ll start with manually for now.
We first need to add a physical interface into the Etherchannel. We’re going to start with gig0/1. Under the interface configuration we enter channel-group 5 mode on.
Notice the number ‘5’? This represents the logical interface that we’re creating. It can be basically any reasonable number. We’ll add a second interface to channel-group 5 soon.
Do you also notice the mode on? The mode is whether it’s manual or dynamic. Using the on keyword means we’re manually configuring this channel-group. This means the switch will assume that there’s a valid etherchannel or LAG at the other end of the link.
You’ll also notice that as soon as we leave the interface configuration, a new interface called Port-Channel 5 has been created, and is up.
Let’s jump into interface Gig-0/1, and add it to the same channel-group. If we used a different number here, it would be part of an entirely different EtherChannel. So it’s important to get the number right.
So far, we’ve added physical interfaces gig-0/0 and gig-0/1 to a logical interface, called port-channel5.
We can configure this port-channel interface just like we would configure any other interface. For example, we can configure it as a trunk port. We could just as easily make it an access port, or add an IP address to make it a layer-3 interface.
We’ll also add a description while we’re here.
To check that it’s working, we can use show etherchannel summary.
This shows all the port channels configured on this switch, as well as the physical member interfaces.
There’s also a few flags next to our interfaces, which we can decode using the handy table above. In our case, we can see that we have a layer-2 port channel.
Here’s another quiz question to get you thinking. You might need to try this in a lab or by doing your own research.
Chapter 4 – Dynamic Etherchannels
We can improve etherchannels by making them dynamic. What makes them dynamic? They exchange messages between the two devices, to agree on whether an etherchannel should exist here or not.
Let’s consider why we might want this. Imagine two switches are connected with an etherchannel. But now, someone comes along and moves one of the links to a different device.
This isn’t valid; Etherchannels are intended to be between two devices only.
If this were configured as a manual etherchannel, our switch would continue forwarding traffic over the link, assuming that the other end is configured correctly. This would result in dropped traffic.
However, if it’s dynamic, the switches continually share messages with each other. These will be disrupted in some way, the switch will know there’s a problem, and will shut down the miscabled link.
So dynamic is good. In fact I recommend it whenever it’s supported.
Cisco switches support two types of dynamic etherchannel. What I mean is, there are two different protocols that we can use to exchange messages over the etherchannel. These are LACP and PaGP.
PaGP is an old Cisco only protocol. It’s rarely used anymore, so we’re not going to look at it in any detail at all.
Instead, we’ll focus on LACP. LACP was originally part of the 802.3ad standard. It was then moved into the 802.3ax standard. This makes it vendor-neutral, so we can connect other vendor switches to our Cisco switches (if we want to).
LACP is used to check that both sides are suitable to form an EtherChannel. This means there are certain parameters that need to match on the physical interfaces for the etherchannel to form. These include:
- Speed and duplex
- Access or trunk mode
- The VLANs allowed on the interface
- The native VLAN, if it’s a trunk port
- Spanning-tree settings
Let me show you another reason why we want to use LACP on our Etherchannels.
Sometimes we have a passive device between our switches. Perhaps a media converter, that converts fibre links to copper links.
If the media converter fails, the switch links may stay up. The switches will be blissfully unaware that there’s a problem. They will continue sending traffic over the failed link, resulting in traffic loss.
However, remember that LACP regularly sends messages between our two switches. If there’s a fault in the media converters, or the cables between, then the LACP messages won’t get through.
When these messages go missing, the switches will know there is a problem, and can take an action, such as alerting you, or shutting down the faulty link, allowing regular traffic to flow over the good one.
LACP itself can be in either active or passive mode. An interface in active mode will actively start sending LACP messages when the interface comes online.
An interface in passive mode will only send LACP messages if another device starts sending them first.
So, at least one of the two switches needs to be in active mode for an etherchannel to form dynamically.
Please note that a manual etherchannel does not send or receive LACP messages at all.
Alright, let’s see how it’s configured.
We configure the type when we add physical interfaces to the port-channel. So let’s go back and change interface gig-0/0 and gig-0/1. We previously configured this with mode on, which is a manual etherchannel. We will now remove that configuration.
Notice that this takes the logical interface down? For the Etherchannel to be up, at least one of the member interfaces must also be up. It currently has no member interfaces, so it is down.
Now to configure LACP. We can see that there’s a few modes that we can select from. You’ll notice PaGP as an option here too. We’re going to configure this with mode active. Of course, that brings the etherchannel back up.
Now that’s done, we can use show etherchannel summary to confirm our results.
I recommend using LACP active mode whenever possible. However you will find occasions when you want to configure a LAG or etherchannel to a device that doesn’t support LACP. In this case, a manual etherchannel is your only option.
I’ve thrown in a couple of tricky questions this time. You may find question 4 is particularly tricky.
Chapter 5 – Load Distribution
Let’s talk about how the switches distribute load across the physical links in an etherchannel. For our example, we’re going to assume there are four physical links.
The way this works is a bit complicated. And it can depend on the model of switch you’re using too. It comes down to a process called hashing.
Hashing is used for a lot of different things in the IT world. We’ll see it again when we talk about security later in the series.
A hashing algorithm takes any input, and generates a fixed value as an output. The output is a bit like a signature, that represents the original data.
You can think of it like a library. Books are organised according to category, and are given a number. The number represents the book. Using this number, you can find the book.
Let’s take a very over-simplified example. We’ll pick a number, let’s say 9. This is our original data.
Now for our hashing algorithm. Our algorithm will be to take the original number, and divide it by 4. The result of this calculation is 2, with 1 left over.
We could say that the ‘1’ left over is our hash value. We could take any number we wanted, apply our algorithm, and get a hash value as a result.
So, although real hashing algorithms are far more complicated, basically there’s an input value, and algorithm, and a hash value as a result.
What’s this got to do with etherchannels then?
Think about a frame that needs to be forwarded across the etherchannel. The switch will look at the frame’s details. This might include things like the source and destination MAC address, IP addresses, and port numbers.
It will take these values, and run them through a hashing algorithm, and generate a hash value. To keep it simple for our example, let’s imagine that the hash value will always be 1, 2, 3, or 4.
The switch will assign certain hash values to particular physical links in the etherchannel. So a frame with a hash value of 1 may be sent on physical link 1. A frame with a hash value of 2 may be sent on link 2, and so on.
The real hash values may be more complicated, but hopefully you get the general idea.
At this point, I’d like to clear something up. The hashing algorithm is not LACP. It has nothing to do with LACP. LACP does not decide how traffic is spread across physical links.
The hashing algorithm process is independent, and will run regardless of whether we’re using LACP, PaGP, or manual etherchannels.
Ok. Going back a step, I said that we might use values like source and destination MAC, IPs, ports, etc. The values we use are configurable. And the options you have available vary a little depending on your switch model.
To see what we’re currently using, we can run show etherchannel load-balance. You can see here that we’re currently using source and destination IP’s as the input to our hashing algorithm. We’re not considering MAC addresses or port numbers.
Can we change it? Absolutely! It’s done with the port-channel load-balance command. Here you can see all the methods supported on this switch. Bigger switches will have more options.
Let’s change it to use source and destination MAC address.
So is there any reason why we would want to change the load balancing method? To be honest, in most cases, no. We can leave it at the default setting. However, there are occasions where you will want to. Take a look at this simple example.
In a case like this, traffic forwarded to these servers will go to the router first. When a PC sends a message, what will the destination MAC address be? Not the server, but the router. This is because the source and destination MACs are rewritten on each hop.
What this means, is that when the switch sees the frames coming from the PCs, they will all have the destination MAC of the router.
Now, what would happen if our hashing algorithm looked only at the destination MAC address? As it’s the same value for every frame, each frame would get the same hash value. The result is that all traffic would be assigned to a single physical link. We would say that traffic is pinned to this link.
So if this was happening, we would change our load balancing method to include more information. Maybe source MAC or source IP address. What we want is a lot of variety, which helps to spread the traffic across all physical links in the etherchannel.
The key point to take away from this is that there’s no guarantee that traffic will be evenly spread across these links. We might be expecting 4-Gig of bandwidth, but we might find that we’re getting much less.
We’ll cover a bit more of this in the lab if you’re interested.
Here are the three final quiz questions. I think you’ll enjoy thinking through these ones.
To put all of this into practice, we have this scenario. We want to use Etherchannels in our customer’s network. Someone has even started configuring them for us. However, they can’t get them to work.
You need to find out why they’re not working, and fix them.
The next video is the last in the layer-2 and switching section of our series. Head over to the next video to learn about Power over Ethernet.