Well, the age-old problem in the Layer 2 space is that if I want to connect
these two
switches together and maybe I've got a fiber connection between them, and I say
, "Hey,
I would like some redundancy.
I don't want that one connection going down and breaking the connection between
switches."
As soon as I add that second link, we are going to see Spanning Tree kick into
gear
because we have to prevent the broadcast loops.
I don't want an endless loop of traffic happening here with each broadcast
frame and flooded
frame for that matter, and so Spanning Tree is going to do its job between to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
frame for that matter, and so Spanning Tree is going to do its job between to
block one
of the sides of these links, and now we have prevented the loop.
And so, yeah, it's great that we have loop prevention.
There's not going to be any loops.
But for that matter, we actually do have the redundancy.
If one of these links goes down, Spanning Tree will remove the block and allow
us to
communicate on this.
And so, life is good, but it's not as good as it could be because we're wasting
a whole
lot of bandwidth here.
Imagine these are expensive, maybe in the modern network, expensive 10-gig WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Imagine these are expensive, maybe in the modern network, expensive 10-gig
links.
And so, I paid all this money for 10-gig transceivers and 10-gig quality fiber
between
the two, 10-gig ports on the switches for that matter, and I'm sitting here
with a total
of 10-gig of throughput, even though I purchased enough hardware to have 20-gig
of throughput.
And so, this is going to be where we head for the conversations around our
ether channels.
And there are a lot of conversations to be had. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And there are a lot of conversations to be had.
But the ether channel is an interesting concept.
The idea here is that we will create a bundle of physical links.
So the bundle is on the physical level.
But logically, we have a single link.
It's one logical layer two connection.
And so, at this point, what we can do is we can bundle these two connections
together.
And now, from a layer two perspective, this is treated as if it's one link. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And now, from a layer two perspective, this is treated as if it's one link.
Spanning tree is going to view this as one link.
Our broadcasts are going to view this as one link.
So for example, if a broadcast packet comes into this switch, and we know that
we need
to send a broadcast frame out every single interface on that switch, well, we
're going
to pick one of these and send it out.
We're not going to send it out the other one.
Because by sending it out the one physical link, we've satisfied our
requirement to send
that broadcast frame out that single logical layer two connection.
Now it is worth noting that we can also form a single logical layer three WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now it is worth noting that we can also form a single logical layer three
connection.
But that's not the scope of this conversation.
We're going to be focusing in on layer two ether channels.
And for, I guess, as far as layer three is concerned, we don't really see that
a whole
lot in the real world.
Because when it comes to layer three, routing handles many different links
pretty well.
There's the equal cost of multi-pathing concept.
And so I can just take two layer three links and yeah, I could bundle them WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so I can just take two layer three links and yeah, I could bundle them
together or
I could just leave them separate and effectively get the same result.
And so we don't see a lot of logical layer three links unless we need to save
on IP addresses
or something along those lines.
For the most part, ether channels are more heavily used in the layer two space.
But it is possible to turn them into layer three.
So keep that in mind.
Now when we're bundling ether channel connections, we can have up to eight
connections in iOS
XE.
There are other platforms that actually do support more than this.
But we can support up to eight, meaning that now, if I just draw this again WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But we can support up to eight, meaning that now, if I just draw this again
over here,
now I could have one, two, three, four, five, six, seven, we'll squeeze an
eighth over here.
And we've got eight connections between these two switches.
We can bundle all of these together.
And so rather than only having one active connection and seven that are just
sitting
there idle, now all eight of these are active.
Furthermore, if we're using a dynamic protocol like LACP, we can actually have
eight additional
ports in standby operation, which is incredible because now we're talking about WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
ports in standby operation, which is incredible because now we're talking about
an extra eight.
So one, two, three, four, five, six, seven, eight.
So 16 total where yeah, eight are active.
These are 10 gig links.
We'd have 80 gig of total throughput, but if one of those active links goes
down, one
of these standby links will be inserted into the, into the bundle.
And so maybe we don't have eight standbys.
Maybe we just have a couple of them just in case, but either way, we've got a
lot of flexibility
for establishing these ether channels. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
for establishing these ether channels.
Now importantly, the link types are going to matter here.
The link types must match.
We're talking about matching these links.
This happens on two levels.
First of all, we have to worry about the media type, meaning that I can't
bundle copper and
fiber together.
It just doesn't work.
And furthermore, I also have to match the speeds.
So I can't bundle, for example, one and 10 gig connections.
This isn't an option in the same way that copper and fiber. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
This isn't an option in the same way that copper and fiber.
This wouldn't be an option either.
So we can't mix and match.
We just simply have to have up to eight connections, or again, however many
standbys we want, that
match on both the media type and the speed.
Now an interesting part of this conversation actually has to do with the names
that we
use when we're calling these bundles something.
For example, I've got ether channel written here.
And typically, this is what Cisco likes to use when talking about them.
But believe it or not, an ether channel, this is actually a Cisco term. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But believe it or not, an ether channel, this is actually a Cisco term.
Somebody else calls them ether channels.
This is something that Cisco came up with.
From an industry standard perspective, we typically refer to these as port
channels.
And this is a term that's used even on some of Cisco's platforms.
For example, on the Nexus platforms that are inside of the data center, Cisco
tried
to get away from any Cisco nomenclature, or at least as much as possible.
They even shut off a lot of Cisco protocols that are no longer used. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
They even shut off a lot of Cisco protocols that are no longer used.
And so same thing here when they put together Nexus, they decided to call these
port channels.
And yes, this does impact our show commands that are configuration commands.
For example, on iOS X E.
iOS X E, we're going to have a really well known configuration command that we
want to
run, which is show ether channel summary.
This is a really great command.
It tells us a lot of what's happening. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It tells us a lot of what's happening.
And we'll see this later on when we're configuring ether channels.
But in NXOS, which is running on Nexus, we don't do show ether channel summary.
We do show port channel summary.
And yeah, there's a hyphen in there.
So that is a little bit of a syntax nuance.
And this might show up in other platforms as well, especially for getting our
hands on
non-Cisco gear.
So keep that in mind.
And though I know for me growing up in the Cisco world, I only ever call these
ether channels.
And then to see them all of a sudden being called port channels in a lot of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then to see them all of a sudden being called port channels in a lot of
different
capacities.
That was a little bit of a surprise for me.
Now there are other names as well.
For example, on the server side of things, we call this Nick teaming because
from the
server's perspective, that's what we're doing.
We're taking a server and we have a couple of nicks in here.
And so we pull them up to a local switch and then we can bundle these together.
So we might refer to this as an ether channel or a port channel.
And the server team is going to call this that Nick team. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And the server team is going to call this that Nick team.
So be aware that that term exists.
And lastly, another term that Cisco does like to use in a lot of other industry
, the
manufacturers do as well, is the concept of the lag.
The lag stands for link aggregation.
And we just take the L and the AG there, we call it a lag.
And no different than any of these other concepts here, they all mean the same
thing. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
thing.
But Cisco is especially going to use this lag term as far as their wireless LAN
controllers
and especially their legacy wireless LAN controllers.
But it's still used in wireless vernacular today.
Even from a Cisco perspective, where Cisco clearly likes to use a lot of
different terms,
not just the ether channel term that they created, but also port channels and l
ags.
And it just, no matter which term we see, it's all referring to the same
concept and
that's the primary takeaway here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that's the primary takeaway here.
Now there are also on top of all of this different modes of running our port
channels or ether
channels in.
And typically, in a lot of cases, we're going to see one of a couple modes,
either a static
mode of operation where I hard set this and I say, hey, these eight ports, you
guys are
in a port channel and you ports down here, you're in a port channel.
And I hard map this, I statically configure this. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And I hard map this, I statically configure this.
This is going to have some amount of parallels to the trunk operation that we
just talked
about because with trunks, I could configure it statically or I could configure
it dynamically.
And if we're doing it dynamically, this is going to rely on negotiation.
So again, just like we just talked about, if you're working your way through
this course
sequentially, we just looked at ethernet trunks and the fact that we can
dynamically negotiate
trunk links, we can do the same thing here.
So this is a great way to try to prevent misconfiguration, because let's say I WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So this is a great way to try to prevent misconfiguration, because let's say I
just
have four links and I properly configure the first three ports.
But on this last one, I say, hey, you are in a port channel, but I forget to
configure
it on this side.
Well this creates a really awkward situation because the top switch is bundling
three, four
connections and the bottom switch is only bundling three connections.
This is a huge mistake and can create loops or otherwise create inconsistent WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
This is a huge mistake and can create loops or otherwise create inconsistent
traffic flows
and we want to avoid this at all cost.
But if I'm statically configuring it, there's nothing on the switches that will
recognize
that this is happening.
Instead, I can use dynamic negotiation and I can tell all of these ports to try
to negotiate
a port channel.
So what happens again if I properly configure it on all four of these ports up
top, but
I accidentally only put it on three on the bottom. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I accidentally only put it on three on the bottom.
Well at this point, the negotiation is going to work for three of these
connections and
even though the top switch is trying to negotiate adding this link into the
bundle, the other
side is not going to respond.
And so we actually properly only bundle three of these connections together.
So there's a lot of advantage to using a dynamic protocol, not the least of
which is the fact
that now we can take advantage of, well, yeah, the active and standby
methodology. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
methodology.
This requires dynamic configuration.
I can't do that in the static world.
So again, this helps us with consistent configuration and it helps us by
delivering the standby concept.
Now there are two protocols that we can use for dynamic ether channel
configuration.
The first is the industry standard LACP, which is pretty much what we use today
.
And then we also have Cisco's version, which is port aggregation protocol, PAGP WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then we also have Cisco's version, which is port aggregation protocol, PAGP
.
Now even though iOS XE continues to support PAGP, Cisco has disabled it on
other platforms.
For example, Nexus doesn't support PAGP.
And generally speaking, we're going to see that we just like to use LACP.
So it's again, there's a lot of parallels between ether channels and trunks as
far as
iOS XE is concerned, because even though Cisco supported ISL for a long time,
they eventually
got rid of it because nobody was using it.
Meanwhile, PAGP, they do still support, but nobody really uses it for the most WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Meanwhile, PAGP, they do still support, but nobody really uses it for the most
part.
We're primarily relying on LACP, but it was the port aggregation protocol.
The name is right there.
It was the protocol that Cisco supported before the industry had an option,
which again is
LACP.
So here's our industry standard.
Here's our Cisco flavor.
And in the real world, we're usually going to see LACP.
[BLANK_AUDIO]