When we connect two switches together,
we need to think about things like what happens if that link fails?
And do we have enough bandwidth between these two switches,
so to increase redundancy and to add extra bandwidth
We're going to use a technology called Ether channels.
We've recently been talking about spanning tree.
What would spanning Tree do in a case like the one you see here?
He would effectively block one link to prevent the loop, right?
But we still need to consider having two links here for redundancy,
that is, if one link fails, the other would be available to take over.
The second link is basically a backup in case the first link fails.
This is good, but it could be better,
let's say these are both one gig links.
What happens if we have high levels of traffic?
If there's more than one gig of traffic, this one 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 in that case where we had two links between a switch,
we could configure them as an etherchannel and they would pretend
or act like they're a single link with up to two gig of bandwidth.
And because it appears as a single link spanning tree wouldn't block anything.
So both physical links can be active at once.
If one physical link fails,
the the channel still works as normal with diminished bandwidth, of course,
this means that spanning tree doesn't need to recalculate or send TCNs
or do anything like that as long as at least one physical link is up.
The logical link will stay up.
You can usually have up to eight physical interfaces in an ether channel,
some switches allow you to go as high as 16.
Before moving on, there's a couple of things I'd like to briefly mention.
Firstly, Ether channel is a Cisco term.
They also call it a port channel or channel group,
as these are the commands that we use in configuration.
Other vendors will use terms like LAG, which is Link Aggregation Group,
or perhaps AE, which is short for aggregated ethernet.
Despite the different names.
These are all standards based.
So that means that you can configure an Ether channel on a Cisco switch
and connect it
to a lag on another vendor's switch, and it will all continue to work just fine.
And of course, we always have some quiz questions through these videos.
So here are a few to get you started.
Etherchannels can be configured either manually or dynamically.
We'll start by looking at 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, we're going to enter the command
channel Group five mode on.
Notice number five?
This represents the logical interface that we're creating.
It can be any reasonable number.
We'll soon
add a second interface to this channel group.
But first, do you notice that we say mode on
the mode is whether this is manual or dynamic
Using the on key word means that we're manually configuring this channel group.
This means a switch will assume that there is 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
five has been created and is up.
Let's jump into another interface, and we'll add that
into the same channel group.
If we use a different number here,
it would be part of an entirely different ether channel.
So it's important to get the number right.
So far,
we've added physical interfaces gig 0/0 and 0/1
to a logical interface called Port Channel five.
We can configure this port channel interface just as we would
for any other interface.
For example, we could 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 three interface.
We'll just add a description while we're here.
To check if it's working, we can use the command
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, you can see that we have a layer two port channel.
Now, here's another quiz to get you thinking
you might need to try this in a lab or by doing your own research.
As always, though, it'll be time well-spent.
We can improve on Ether channels
by making them dynamic. what makes them dynamic?
They exchange messages between the two devices to agree
on whether an ether channel should exist 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.
Now, this isn't valid. Etherchannels are intended to be between two devices only.
If this were configured as a manual ether channel,
our switch would continue forwarding traffic over the link,
assuming that the other end is also correctly configured,
this would result in traffic being dropped.
However, if it's dynamic, the switches continually share messages
with each other.
If these are disrupted in some way, the switch will know
there's a problem and we'll shut down the miss-cabled link.
So dynamic is good.
In fact, I recommend it wherever it's supported.
Cisco support two types of dynamic ether channel.
What I mean is
there are two different protocols
that we can use to exchange messages over the Ether channel.
These are called LACP and PAGP.
Pagp is an old Cisco only protocol is rarely used anymore,
so we're not going to look at it in any detail at all.
Instead, we're going to 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 vendors switches to our Cisco switches if we want to.
LACP is used to check that both sides are suitable to form an either channel.
This means there are certain parameters that need to match
on the physical interfaces for the Ether channel to form.
These include the speed and duplex. Access mode or trunk mode.
The VLANs allowed on the interface the native VLAN, if it's a trunk port
and 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 fiber links to copper links.
If the media converter fails,
the Switch links may appear to stay up.
The switches are blissfully unaware that there's a problem.
They will continue sending traffic over the failed link
or rather trying to, which results in traffic loss.
However, remember that
LACP regularly sends messages between our switches.
If there's a fault in the media converters or the cables between them,
then the LCP messages won't get through.
When these messages go missing,
the switches will know that there's 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 link.
LACP Itself can be either in 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 ether channel to form dynamically.
Please note,
a manual ether channel does not send or receive
LACP messages at all.
OK. Let's see how it's configured.
We configure the type when we add physical interfaces into the port channel.
So let's go back and change interface gig 0/0 and 0/1.
We previously configured this with mode on which is a manual
ether channel. We'll now remove that configuration.
Notice this takes a 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's down.
Now to configure LACP
There's a few modes we can select from.
We're going to configure this with mode active.
Of course, that brings the Ether channel back up.
Now that's done,
we can use show either channel summary to confirm our results.
I recommend
that you use LACP Active Mode wherever possible,
however, you will find occasions when you want to configure LAG
or an ether channel to a device that doesn't support LACP.
In this case, a manual ether channel is your only option.
I've thrown a couple of tricky questions in this time,
you may find Question four to be particularly
tricky.
Let's talk for a while on how
switches distribute load across the physical links in an etherchannel.
For our example, we're going to assume that 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.
But it essentially comes down to a process called hashing.
Hashing is used for a lot of things in the IT world.
We'll see it again when we talk about security later in the series.
Hashing algorithm takes any input
and generates a fixed value as an output.
The output that it generates is a bit like a signature,
and that signature represents the original data.
You can think of it a bit like you're in a library.
Books are organized according to category and given a number.
This number represents the book.
Using this number, you can find the book.
Let's take a very oversimplified example.
We'll pick a number, let's say, nine.
This is our original data.
Now for our hashing algorithm.
Our algorithm will be to take the original number and divide it by four.
The result of this is two with one left over.
We could say that the one 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
than what I've just explained, basically there's an input value
and there's an algorithm and there's a hash value that we have as a result.
So what's this got to do with ether channels?
Think about a frame that needs to be forwarded across the Ether channel.
The switch will look at the Frames details.
This might include things like source and destination Mac address,
IP addresses and port numbers.
They will take these values and run them through a hashing algorithm
and generate a hash value to keep it simple, for example,
let's imagine that a hash value will always be one, two, three or four.
The switch will assign certain hash values to particular
physical links in the Ether channel.
So a frame with a hash value of one
may be sent on the physical link, one
frame with hash value of two, maybe sent on lnk two, and so on.
The real hash values may be a bit more complicated,
but I'm hoping you get the general idea.
At this point, though, 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 these links.
The hashing algorithm process is independent
and will run regardless of whether we're using LACP, PAGP,
or manual either channels.
Going back a step, I said that we might use values
like source and destination Mac, IPs, ports and so on.
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 a channel load balance.
You can see here that we're currently using source and destination
IPs 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 addresses.
So is there any reason we
would want to change the load balancing method?
To be honest,
in a lot of cases, no, we can leave it happily at the default setting.
However, there are occasions where we will want to.
Let's take a look at this simple example.
In a case like this, traffic forwarded to
these servers will go to the router of first.
When a PC sends a message.
What will the destination Mac address be?
It won't be the server's MAC.
It'll be the router's Mac.
This is because the source and destination MACs are rewritten at each layer
three 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 one physical link.
We could say that the 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 really want is a lot of variety which helps to spread
the traffic across the physical links in the Ether channel.
The key point to take away from this is that there is no guarantee
that traffic will be evenly spread across these links.
We might be expecting 4G of bandwidth,
but we might find that we're getting a bit less.
We'll cover this a bit more in the lab if you're interested in taking a look.
And here are the final three quiz questions
I think you'll enjoy thinking these ones through.
To put all this in practice, we have this scenario.
We want to use ether channels in our customers network.
Someone has even started configuring them for us.
However, they don't know how to 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 this series,
head over to the next video to learn about power over Ethernet.