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 linked to prevent the loop, right? But we still need to consider
having two links here for redundancy, but 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. The channel 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 easy channel
and they would pretend or act like they're a single link
with up to two 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 thing 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 DCNS 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 Journal 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 IEEE,
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 connected 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. Either channels 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 user channel. We're going to start with zero slash one. Under the interface,
we're going to enter the command channel Group five mode on. There is No. 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 ether channel 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 00 and 01 to a logical interface called Port
Channel five. We can continue 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 ISA channel 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 away 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 ISA channel. But now someone comes along and moves
one of the links to a different device. Now this isn't valid if the channels 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 Cable 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 LCP and AGP. P-gp 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 LCP. LCP was originally part of the attitude
or three, a standard. It was then moved into the
air two to three extended. This makes it vendor neutral so we can connect other vendors switches
to our Cisco switches if we want to. LCP 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 land if it's a trunk port and spanning three settings. Let me show you another reason why we want to use LCP
on our ISA channels. 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 this, which is a blissfully unaware
that there's a problem. They will continue
sending traffic over the file link or rather trying to,
which results in traffic loss. However, remember that LCP 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. Itself can be either in active or passive mode, an interface in active
mode will actively start sending LCP messages
when the interface comes online. An interface in passive
mode will only send LSAP 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 LCP messages at all. OK. Let's see how it's configured. We can figure the type when we add
physical interfaces into the port channel. So let's go back and change interface
gig 00 and 01. We previously configured this with mode on
which is a manual ether channel will now remove
that configuration. Notice this takes a logical interface
down for the Ether channel to be off, at least one of the member interfaces
must also be up. It currently has no member interfaces,
so it's down. Now you can figure. 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 LCP 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 LCP. In this case, a manual ether
channel is your only option. After a couple of tricky questions
in this time, you may find Question
four to be particularly tricky. Let's talk for a while on House, which is distribute load across
the physical links in another channel. 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 to. But it essentially comes down to a process
called hashing. Housing is used for a lot of things
in the 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 either
channels? Think about a frame that needs
to be folded 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 SoundLink 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 LCP. It has nothing to do with LCP. LCP 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 LCP or manual either channels. Going back a step,
I said that we might use values like source and destination Mac, IP sports
and so on. The values we use are configurable
and the options you have available very 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 IP GPS 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 biggest,
which 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 service, Mark. It'll be the router's Mac. This is because the source and destination
Max are rewritten at each layer three hop. What this means is that when the switch
sees the frames coming from the pieces, they will all have the
destination mac of the outer. 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 either
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 light to and switching section of this series, head over to the next video
to learn about power over Ethernet.
