WEBVTT

0:00:03.160000 --> 0:00:08.580000
 Hello and welcome this video on a review
 of port bundling with ether channel.

0:00:08.580000 --> 0:00:13.160000
 So let's talk about the quick refresher
 on the concepts of this.

0:00:13.160000 --> 0:00:19.680000
 So the idea behind port bundling also called
 link aggregation, just depending

0:00:19.680000 --> 0:00:23.240000
 on who you're talking to, what document
 you're reading, is that like it

0:00:23.240000 --> 0:00:26.080000
 says here, it aggregates redundant
 links into a bundle.

0:00:26.080000 --> 0:00:29.720000
 Now let's just do a quick refresh rank,
 why you'd want to do something

0:00:29.720000 --> 0:00:35.480000
 like that. So recall that if I have
 a switch and it has multiple links

0:00:35.480000 --> 0:00:40.440000
 to something, let's just say another
 switch for all intents and purposes.

0:00:40.440000 --> 0:00:43.280000
 So here we have a switch one
 and here we have switch two.

0:00:43.280000 --> 0:00:46.920000
 Remember that switches by default are
 running spanning tree and spanning

0:00:46.920000 --> 0:00:50.860000
 tree sees this as a whole bunch of looping
 opportunities and span trees

0:00:50.860000 --> 0:00:53.340000
 says, hey, look, we got to
 block some links here.

0:00:53.340000 --> 0:00:57.700000
 So it's spanning tree will do is it'll
 pick one switch to be your root

0:00:57.700000 --> 0:01:02.200000
 bridge. And that guy, all of his ports
 will be forwarding as designated

0:01:02.200000 --> 0:01:07.500000
 ports. On the other switch, he'll choose
 one port as his root port and

0:01:07.500000 --> 0:01:12.460000
 go forwarding there, but then he'll
 end up blocking everything else.

0:01:12.460000 --> 0:01:17.060000
 So you've added these redundant links
 because probably you wanted more

0:01:17.060000 --> 0:01:20.560000
 bandwidth. You know, it's great
 to have redundancy, right?

0:01:20.560000 --> 0:01:25.220000
 If your sole purpose was, hey, my
 top link right here, that's fine.

0:01:25.220000 --> 0:01:27.820000
 I got enough bandwidth there
 to do everything I need.

0:01:27.820000 --> 0:01:31.520000
 I just want to have some additional
 links just in case that link fails.

0:01:31.520000 --> 0:01:34.280000
 Okay. Well, then you can have some
 additional standalone links and the

0:01:34.280000 --> 0:01:37.940000
 fact that they're blocking won't be a
 problem because they're backup links

0:01:37.940000 --> 0:01:43.260000
 anyway. And if that top link fails and
 goes away, spanning tree will account

0:01:43.260000 --> 0:01:46.360000
 for that and end up forwarding
 one of those block links.

0:01:46.360000 --> 0:01:47.780000
 So you get your redundancy there.

0:01:47.780000 --> 0:01:49.760000
 But what you don't get
 is extra bandwidth.

0:01:49.760000 --> 0:01:52.980000
 So if you said, hey, that one
 top link, that's not enough.

0:01:52.980000 --> 0:01:54.260000
 I'm congesting that link.

0:01:54.260000 --> 0:01:57.460000
 Frames are being dropped because it's
 not enough bandwidth to carry all

0:01:57.460000 --> 0:01:58.420000
 the stuff I need.

0:01:58.420000 --> 0:02:01.340000
 I need some additional bandwidth
 between these switches.

0:02:01.340000 --> 0:02:05.820000
 And if that was the reason why you added
 some additional links, now you're

0:02:05.820000 --> 0:02:08.800000
 going to be dissatisfied because those
 additional links you added aren't

0:02:08.800000 --> 0:02:12.260000
 being used because they're
 blocked by spanning tree.

0:02:12.260000 --> 0:02:16.920000
 So just as a review here as a refresher,
 remember that the whole reason

0:02:16.920000 --> 0:02:23.140000
 why spanning tree does this is because
 if a frame like a broadcast came

0:02:23.140000 --> 0:02:27.960000
 in right here and the root bread said,
 okay, well, I'm going to let's

0:02:27.960000 --> 0:02:33.260000
 just say for a moment that these
 links were not all blocked.

0:02:33.260000 --> 0:02:36.300000
 All right, let's say
 they were forwarded.

0:02:36.300000 --> 0:02:39.040000
 Let's say spanning
 tree did not exist.

0:02:39.040000 --> 0:02:43.660000
 And let's just say that that frame
 was flooded out right here.

0:02:43.660000 --> 0:02:45.700000
 Well, then switch to
 would turn around.

0:02:45.700000 --> 0:02:48.500000
 And if it's a broadcast, he would turn
 around and flood it back this way

0:02:48.500000 --> 0:02:50.480000
 and flood it back that way.

0:02:50.480000 --> 0:02:53.980000
 And it would end up circling right if
 it came in this way, then it ended

0:02:53.980000 --> 0:02:56.820000
 up flooding out here and
 flooding out here.

0:02:56.820000 --> 0:03:02.900000
 So what we really want to do with ether
 channeling, what the goal or purpose

0:03:02.900000 --> 0:03:09.520000
 of ether channeling is is to say, hey,
 when a frame comes in, let's just

0:03:09.520000 --> 0:03:11.720000
 say this is port one right here.

0:03:11.720000 --> 0:03:14.600000
 And then we have port
 two, port three.

0:03:14.600000 --> 0:03:19.460000
 When a frame comes in interface or
 port number one, and it needs to be

0:03:19.460000 --> 0:03:22.640000
 flooded, it's an unknown
 destination.

0:03:22.640000 --> 0:03:25.740000
 Don't flood it out
 ports two or three.

0:03:25.740000 --> 0:03:29.640000
 Why? Well, because we want to consider
 ports one, two and threes all part

0:03:29.640000 --> 0:03:34.300000
 of a group. If they're all part of
 the same group, and we have a rule

0:03:34.300000 --> 0:03:39.160000
 that says, hey, if a frame comes in
 any port in that group, then needs

0:03:39.160000 --> 0:03:44.200000
 to be flooded. It cannot be flooded
 out any port in that same group.

0:03:44.200000 --> 0:03:46.560000
 You can flood out other ports, but
 not ports in that same group.

0:03:46.560000 --> 0:03:49.980000
 If we could do that, then we could
 have this wide open right here.

0:03:49.980000 --> 0:03:51.920000
 And that's exactly what
 ether channeling does.

0:03:51.920000 --> 0:03:57.360000
 When we bundle both sides of this into
 ether channels, now we have a logical

0:03:57.360000 --> 0:04:02.160000
 interface called a port channel
 interface that's created.

0:04:02.160000 --> 0:04:06.080000
 You don't have to create it'll
 be created on the fly.

0:04:06.080000 --> 0:04:09.760000
 And this port channel interface will
 control will basically represent

0:04:09.760000 --> 0:04:14.060000
 the group that all of these
 interfaces are in.

0:04:14.060000 --> 0:04:16.540000
 And now we have that rule in places
 that says, hey, if something comes

0:04:16.540000 --> 0:04:20.300000
 in this group that needs to be flooded,
 we cannot flood it back out this

0:04:20.300000 --> 0:04:24.340000
 exact same group or any other
 ports in this group.

0:04:24.340000 --> 0:04:26.300000
 And that's the whole idea
 behind ether channel.

0:04:26.300000 --> 0:04:29.620000
 And now, Spain tree says, okay, I can
 forward everything and I've got

0:04:29.620000 --> 0:04:31.500000
 all my additional bandwidth.

0:04:31.500000 --> 0:04:35.040000
 So that's the real benefit
 behind either channel.

0:04:35.040000 --> 0:04:39.860000
 So provides aggregated bandwidth
 and it avoids congestion.

0:04:39.860000 --> 0:04:46.380000
 Now, as far as load balancing is concerned,
 now we're talking about layer

0:04:46.380000 --> 0:04:52.300000
 two here. And what I mean by layer two
 is, you know, when you think about

0:04:52.300000 --> 0:04:58.540000
 layer three, when you think about IP,
 if I was a router and I had two

0:04:58.540000 --> 0:05:02.400000
 or more links to something and I got
 in an IP packet, I could certainly

0:05:02.400000 --> 0:05:07.240000
 fragment that IP packet and send one fragment
 out this direction and another

0:05:07.240000 --> 0:05:08.440000
 fragment out that direction.

0:05:08.440000 --> 0:05:09.580000
 I could do that.

0:05:09.580000 --> 0:05:12.260000
 But at layer two, you
 can't really do that.

0:05:12.260000 --> 0:05:15.180000
 You can't fragment
 ethernet frames.

0:05:15.180000 --> 0:05:19.540000
 So when an ethernet frame comes in here
 to switch number one, even though

0:05:19.540000 --> 0:05:24.160000
 these three links here are bundled,
 one of the physical ports will have

0:05:24.160000 --> 0:05:28.180000
 to be selected for transmission of that
 frame, maybe the one here in the

0:05:28.180000 --> 0:05:32.800000
 middle. And there's something called an
 ether channel load balancing algorithm

0:05:32.800000 --> 0:05:34.100000
 that dictates that.

0:05:34.100000 --> 0:05:37.140000
 So when a frame comes in, the load
 balancing algorithm says, oh, I see

0:05:37.140000 --> 0:05:41.420000
 three ports in this channel or five
 ports in this channel, let me run

0:05:41.420000 --> 0:05:44.720000
 an algorithm based on what I see in
 this frame and the results of the

0:05:44.720000 --> 0:05:49.280000
 algorithm will tell me which interface
 to select to go out.

0:05:49.280000 --> 0:05:55.220000
 The default ether channel load balancing
 load balancing algorithm, at

0:05:55.220000 --> 0:06:01.140000
 least in Cisco switches, is to
 use the source MAC address.

0:06:01.140000 --> 0:06:05.720000
 So when a frame comes in, the source
 MAC address is extracted, the bits

0:06:05.720000 --> 0:06:08.720000
 from the source MAC address, it's plugged
 in this algorithm and then based

0:06:08.720000 --> 0:06:12.600000
 on that, the algorithm will select which
 physical interface in the channel

0:06:12.600000 --> 0:06:16.580000
 group to use in the bundle
 to use to forward.

0:06:16.580000 --> 0:06:21.800000
 Because of that, all frames from the
 same source MAC address will always

0:06:21.800000 --> 0:06:24.980000
 choose the exact same path.

0:06:24.980000 --> 0:06:27.440000
 So think about this for a moment.

0:06:27.440000 --> 0:06:30.060000
 Let's just go ahead and delete
 this and redraw it.

0:06:30.060000 --> 0:06:33.140000
 Let's say that our situation
 was like this.

0:06:33.140000 --> 0:06:42.580000
 Let's say we had two switches with
 a three port ether channel.

0:06:42.580000 --> 0:06:52.220000
 So this is switch one, this is switch
 two, and here we have a server.

0:06:52.220000 --> 0:06:55.860000
 Maybe our company web server
 or whatever it happens to be.

0:06:55.860000 --> 0:07:01.440000
 All right. And over here is where we
 have our various hosts, laptops,

0:07:01.440000 --> 0:07:03.480000
 PCs, you know, what not.

0:07:03.480000 --> 0:07:08.040000
 Well, if we let ether channel default
 to the source MAC address for its

0:07:08.040000 --> 0:07:13.920000
 load balancing selection, that means
 when this guy right here sends all

0:07:13.920000 --> 0:07:17.340000
 of his frames to that server, that
 load balancing algorithm will look

0:07:17.340000 --> 0:07:20.660000
 at his source MAC address, which never
 changes, and he'll choose one of

0:07:20.660000 --> 0:07:23.880000
 these links for him,
 maybe the top link.

0:07:23.880000 --> 0:07:27.160000
 So whenever he goes to the server, he'll
 always be going across the top

0:07:27.160000 --> 0:07:30.980000
 link. Now the idea though is that if there's
 enough, you know, randomization

0:07:30.980000 --> 0:07:35.200000
 and source MAC addresses the next guy
 that sends something, hopefully

0:07:35.200000 --> 0:07:39.060000
 the load balancing algorithm will choose
 a different link for all of his

0:07:39.060000 --> 0:07:46.100000
 traffic. So as we go from left to right,
 hopefully our frames will be

0:07:46.100000 --> 0:07:49.800000
 load balanced because they're all coming
 from different source MAC addresses.

0:07:49.800000 --> 0:07:51.680000
 But here's the problem.

0:07:51.680000 --> 0:07:56.020000
 What about when that server is returning
 the traffic from right to left?

0:07:56.020000 --> 0:07:59.260000
 He only has one MAC
 address, right?

0:07:59.260000 --> 0:08:03.140000
 So when he goes to reply to this traffic,
 whether he's replying to the

0:08:03.140000 --> 0:08:07.380000
 pink guy, the blue guy, or the green
 guy, his replies are all coming from

0:08:07.380000 --> 0:08:09.200000
 one source MAC. So guess what?

0:08:09.200000 --> 0:08:13.480000
 His reply traffic is always
 going to take just one link.

0:08:13.480000 --> 0:08:18.720000
 So going from right to left, we're not
 doing any load balancing whatsoever.

0:08:18.720000 --> 0:08:24.620000
 Now fortunately for us, there is a command
 in which you can modify that

0:08:24.620000 --> 0:08:28.160000
 load balancing algorithm to give
 it a little bit more flexibility.

0:08:28.160000 --> 0:08:34.200000
 For example, that command, you could
 change that command and say, well

0:08:34.200000 --> 0:08:44.080000
 instead of source with load balancing
 on source and destination IP address.

0:08:44.080000 --> 0:08:50.820000
 Now if the server is responding to the
 pink guy, that is one source and

0:08:50.820000 --> 0:08:55.480000
 destination IP address that's different
 than if that server is responding

0:08:55.480000 --> 0:08:56.700000
 to the blue guy.

0:08:56.700000 --> 0:09:00.200000
 That would be a different source and
 destination IP address pairing.

0:09:00.200000 --> 0:09:02.660000
 And that would hopefully be
 load balanced differently.

0:09:02.660000 --> 0:09:04.920000
 In just a moment, I'll show
 you the algorithm for that.

0:09:04.920000 --> 0:09:08.060000
 But just be aware, that's why it says here
 that load balancing uses different

0:09:08.060000 --> 0:09:12.560000
 algorithms. It sticks to one source
 MAC address as the default, but in

0:09:12.560000 --> 0:09:16.700000
 situations like that or others, it might
 benefit you to change that load

0:09:16.700000 --> 0:09:20.200000
 balancing algorithm to one of like
 six or seven different options that

0:09:20.200000 --> 0:09:29.620000
 you have available.

0:09:29.620000 --> 0:09:34.660000
 You can bundle up to eight interfaces
 in an active ether channel.

0:09:34.660000 --> 0:09:41.080000
 And the main thing to remember when doing
 this is that all the ports really

0:09:41.080000 --> 0:09:42.440000
 need to be the same.

0:09:42.440000 --> 0:09:45.560000
 Now here it says all the ports should
 have the same speed and duplex.

0:09:45.560000 --> 0:09:46.840000
 That's absolutely true.

0:09:46.840000 --> 0:09:51.800000
 You can't bundle a fast ethernet port
 with a gigabit port into an ether

0:09:51.800000 --> 0:09:53.260000
 channel bundle. That won't work.

0:09:53.260000 --> 0:09:55.500000
 They don't have the same speed.

0:09:55.500000 --> 0:09:59.020000
 Certainly the duplex has to match, but
 above and beyond that, the actual

0:09:59.020000 --> 0:10:02.660000
 configuration on the interfaces
 has to be the same.

0:10:02.660000 --> 0:10:07.040000
 I might have two interfaces which are
 both one gig interfaces, but if

0:10:07.040000 --> 0:10:10.520000
 one is configured as a trunk and one
 is configured as an access switch

0:10:10.520000 --> 0:10:12.420000
 port, that won't work.

0:10:12.420000 --> 0:10:13.660000
 Their configurations don't match.

0:10:13.660000 --> 0:10:14.680000
 They can't be bundled.

0:10:14.680000 --> 0:10:19.240000
 What I usually do is after I identify
 which interfaces I want to bundle

0:10:19.240000 --> 0:10:22.540000
 into my ether channel, the very first
 thing I do before I do any ether

0:10:22.540000 --> 0:10:26.740000
 channel commands at all is I just
 issue a show run on my switch.

0:10:26.740000 --> 0:10:29.160000
 I look at the configuration
 of the ports in question.

0:10:29.160000 --> 0:10:33.140000
 If those ports look like they're configured
 identically, I'm good to go.

0:10:33.140000 --> 0:10:36.080000
 I can issue one command,
 bundle them together.

0:10:36.080000 --> 0:10:40.260000
 If I see any variation in their configuration,
 I got to fix that first,

0:10:40.260000 --> 0:10:46.320000
 make them identical before
 I do my bundling command.

0:10:46.320000 --> 0:10:51.720000
 It provides a layer two
 loop free network.

0:10:51.720000 --> 0:10:56.820000
 All right. Just like with trunking, with
 VLAN trunking, with VLAN trunking,

0:10:56.820000 --> 0:10:58.900000
 you had a choice of
 one of two things.

0:10:58.900000 --> 0:11:01.860000
 You can either say, well, I'm
 going to do a static trunk.

0:11:01.860000 --> 0:11:04.640000
 In other words, I'm not going to do
 any negotiation or dynamic stuff.

0:11:04.640000 --> 0:11:07.940000
 I mean, it's going to tell this interface
 switch port mode trunk.

0:11:07.940000 --> 0:11:08.800000
 You are trunking.

0:11:08.800000 --> 0:11:09.900000
 You don't have a choice.

0:11:09.900000 --> 0:11:12.500000
 Regardless of what you're connected
 to on the other side.

0:11:12.500000 --> 0:11:14.940000
 Or I could have done
 dynamic trunking.

0:11:14.940000 --> 0:11:18.220000
 I could have used a protocol to negotiate
 the trunk, bring up the trunk

0:11:18.220000 --> 0:11:19.440000
 and maintain the trunk.

0:11:19.440000 --> 0:11:23.540000
 Now, with VLAN trunking, there was only
 one protocol that could do that

0:11:23.540000 --> 0:11:27.220000
 for you, which was Cisco's
 dynamic trunking protocol.

0:11:27.220000 --> 0:11:28.360000
 It was Cisco proprietary.

0:11:28.360000 --> 0:11:32.200000
 So that was only an option if you were
 doing VLAN trunking from one Cisco

0:11:32.200000 --> 0:11:34.100000
 switch to another Cisco switch.

0:11:34.100000 --> 0:11:37.320000
 Anything else? Dynamic trunking
 was not an option.

0:11:37.320000 --> 0:11:38.940000
 You had to do static trunking.

0:11:38.940000 --> 0:11:43.680000
 Well, with ether channeling, you have
 the same high level two options.

0:11:43.680000 --> 0:11:48.300000
 You could force up to eight lengths
 into an ether channel, regardless

0:11:48.300000 --> 0:11:50.000000
 of what they're connected
 to on the other side.

0:11:50.000000 --> 0:11:53.080000
 And remember, if one size ether channel,
 the other side also needs to

0:11:53.080000 --> 0:11:55.960000
 be ether channeled, or you can actually
 end up with bridging loops if

0:11:55.960000 --> 0:12:00.900000
 you don't. So I could force an ether
 channel or I could use a dynamic

0:12:00.900000 --> 0:12:03.440000
 protocol to negotiate and
 bring up my ether channel.

0:12:03.440000 --> 0:12:06.640000
 Here's where it differs
 from VLAN trucks.

0:12:06.640000 --> 0:12:11.320000
 With ether channeling, if I want
 to do dynamic, I have a choice.

0:12:11.320000 --> 0:12:14.740000
 One thing I could use is the
 port aggregation protocol.

0:12:14.740000 --> 0:12:16.660000
 This is Cisco proprietary.

0:12:16.660000 --> 0:12:21.720000
 This was like the first protocol that came
 out to do dynamic ether channeling.

0:12:21.720000 --> 0:12:25.800000
 Now on, that's not
 a feature of PAGP.

0:12:25.800000 --> 0:12:27.940000
 That's just statically forcing
 it to be a trunk.

0:12:27.940000 --> 0:12:29.780000
 So that really shouldn't
 even be in this slide.

0:12:29.780000 --> 0:12:32.160000
 But desirable and auto, they are.

0:12:32.160000 --> 0:12:37.100000
 And the keywords of desirable and auto
 work the same way for ether channeling

0:12:37.100000 --> 0:12:39.140000
 that they did in the
 world of trunking.

0:12:39.140000 --> 0:12:42.600000
 Same thing. Desirable means I'm going
 to initiate whatever the protocol

0:12:42.600000 --> 0:12:46.160000
 is I'm using. I'm going to initiate
 the exchange and see if the other

0:12:46.160000 --> 0:12:50.480000
 side over there is willing to respond
 to my initiation requests.

0:12:50.480000 --> 0:12:51.640000
 That's desirable.

0:12:51.640000 --> 0:12:55.780000
 Auto means I'm going to passively sit
 back and if the other side initiates

0:12:55.780000 --> 0:12:58.420000
 with me, I will go
 ahead and respond.

0:12:58.420000 --> 0:13:03.520000
 So that's PAGP. Or you can use
 an industry standard protocol.

0:13:03.520000 --> 0:13:07.400000
 It's across many different vendors, which
 is the link aggregation control

0:13:07.400000 --> 0:13:13.340000
 protocol. This was standardized
 by 802.3 AD by the IEEE.

0:13:13.340000 --> 0:13:15.900000
 And it's modes once again
 on is not a mode here.

0:13:15.900000 --> 0:13:17.940000
 That's just statically forcing it.


0:13:17.940000 --> 0:13:20.940000
 LACP has the modes of
 active or passive.

0:13:20.940000 --> 0:13:22.040000
 Same type of idea.

0:13:22.040000 --> 0:13:24.100000
 Active means I'm actively
 trying to negotiate.

0:13:24.100000 --> 0:13:26.540000
 I'm actively trying to initialize
 this ether channel.

0:13:26.540000 --> 0:13:28.460000
 Passive means I'm
 passively waiting.

0:13:28.460000 --> 0:13:31.880000
 But the other side to initialize
 the ether channel.

0:13:31.880000 --> 0:13:37.120000
 Now as far as exams are concerned, you
 need to know in a multiple choice

0:13:37.120000 --> 0:13:42.900000
 scenario, if you're presented with active,
 passive, desirable, auto, you

0:13:42.900000 --> 0:13:46.500000
 need to know which of those
 match up to which protocols.

0:13:46.500000 --> 0:13:48.360000
 All right. So that's
 the first thing.

0:13:48.360000 --> 0:14:00.960000
 You got to know that active, auto, desirable,
 passive, you need to know

0:14:00.960000 --> 0:14:10.840000
 that active matches LACP, auto matches
 PAGP, desirable matches PAGP, passive

0:14:10.840000 --> 0:14:16.260000
 matches LACP. You should be able to
 fill out a chart like that yourself.

0:14:16.260000 --> 0:14:21.820000
 And you should know which modes will
 work to form an ether channel.

0:14:21.820000 --> 0:14:30.540000
 In other words, active and
 auto would not work.

0:14:30.540000 --> 0:14:36.300000
 Because you got LACP on one
 side and PAGP on the other.

0:14:36.300000 --> 0:14:45.160000
 Those two can't talk
 to each other.

0:14:45.160000 --> 0:14:49.560000
 You got PAGP on one side,
 LACP on the other side.

0:14:49.560000 --> 0:14:53.440000
 So both sides of the link have to
 be speaking the same protocol.

0:14:53.440000 --> 0:14:56.780000
 And even if they are, it
 doesn't always work.

0:14:56.780000 --> 0:15:00.980000
 For example, if you have auto on one
 side and auto on the other side,

0:15:00.980000 --> 0:15:03.700000
 well now you've got both
 of them running PAGP.

0:15:03.700000 --> 0:15:06.060000
 So the protocol is the same.

0:15:06.060000 --> 0:15:10.700000
 But neither one of them is initiating
 because auto is silent.

0:15:10.700000 --> 0:15:11.880000
 It's not doing anything.

0:15:11.880000 --> 0:15:13.580000
 It's waiting for the other
 side to initialize.

0:15:13.580000 --> 0:15:19.840000
 Or if you have passive on both sides,
 they're both doing LACP, but same

0:15:19.840000 --> 0:15:21.740000
 problem. They're both passive.

0:15:21.740000 --> 0:15:23.580000
 Neither one is initializing.

0:15:23.580000 --> 0:15:29.420000
 So make sure that you're familiar with
 which keywords go with which protocol

0:15:29.420000 --> 0:15:34.900000
 and which keywords will successfully
 form an ether channel between them.

0:15:34.900000 --> 0:15:41.800000
 All right, let's look at some
 configuration commands here.

0:15:41.800000 --> 0:15:44.920000
 So after you've already identified
 the ports you want to be as part of

0:15:44.920000 --> 0:15:47.260000
 your, part of your ether channel and
 after you've already looked at the

0:15:47.260000 --> 0:15:50.640000
 configuration and verified that they
 are configured identically, this

0:15:50.640000 --> 0:15:52.640000
 is the last thing you would do.

0:15:52.640000 --> 0:15:56.600000
 You would typically use the interface
 range command, right?

0:15:56.600000 --> 0:15:59.660000
 Because you want to configure all
 these ports at the same time.

0:15:59.660000 --> 0:16:03.040000
 The interface range gigabit zero zero
 through zero three or whatever it

0:16:03.040000 --> 0:16:07.680000
 is. And then you would say channel
 dash group, select a group number.

0:16:07.680000 --> 0:16:11.700000
 The number you select
 is really irrelevant.

0:16:11.700000 --> 0:16:15.100000
 The only thing to be aware of as far
 as the group number, you know, no

0:16:15.100000 --> 0:16:18.640000
 exam questions are going to say, what
 is the range of group numbers you

0:16:18.640000 --> 0:16:19.680000
 have available to you?

0:16:19.680000 --> 0:16:21.320000
 No one's going to ask you that.

0:16:21.320000 --> 0:16:23.300000
 It actually varies by platform.

0:16:23.300000 --> 0:16:25.920000
 Some platforms, if you do a question
 mark there for group number, will

0:16:25.920000 --> 0:16:30.020000
 say one through twelve, others will
 say like one through forty eight.

0:16:30.020000 --> 0:16:31.120000
 So the range varies.

0:16:31.120000 --> 0:16:33.840000
 Here's the only thing that's
 really important to know.

0:16:33.840000 --> 0:16:39.020000
 Let's say I decide that I want to have
 an ether channel here between switch

0:16:39.020000 --> 0:16:43.820000
 one and switch two and another ether
 channel between switch one and switch

0:16:43.820000 --> 0:16:46.280000
 three. You can absolutely do that.


0:16:46.280000 --> 0:16:50.340000
 On switch one, that just means that you're
 going to have one channel group

0:16:50.340000 --> 0:16:54.360000
 per year and maybe you select channel
 group number one for that and you'll

0:16:54.360000 --> 0:16:57.780000
 have another channel group here and
 maybe select number two for that.

0:16:57.780000 --> 0:17:01.840000
 That's the only thing to remember is that
 these are two independent, distinct

0:17:01.840000 --> 0:17:06.540000
 ether channels. So they need to
 have two unique group numbers.

0:17:06.540000 --> 0:17:09.040000
 The number does not have to
 match on the other side.

0:17:09.040000 --> 0:17:11.740000
 So for example, when you go to switch
 two here and you do this exact same

0:17:11.740000 --> 0:17:15.140000
 command, you can make his channel
 group number twelve.

0:17:15.140000 --> 0:17:18.720000
 But realistically, you probably should
 make them the same so that people

0:17:18.720000 --> 0:17:21.020000
 are looking at the configs,
 they say, wait a second.

0:17:21.020000 --> 0:17:23.780000
 I see channel group one here,
 channel group twelve here.

0:17:23.780000 --> 0:17:24.620000
 Are these the same?

0:17:24.620000 --> 0:17:25.240000
 Are they different?

0:17:25.240000 --> 0:17:26.260000
 Are they going to the same switch?


0:17:26.260000 --> 0:17:29.560000
 Whereas if they both have the same
 number, even though they don't have

0:17:29.560000 --> 0:17:34.760000
 to be, it makes it easier to match them
 up when you're looking at configs.

0:17:34.760000 --> 0:17:41.080000
 And then the protocol you use is dependent
 on what mode you select.

0:17:41.080000 --> 0:17:44.560000
 So you can select from any of those
 modes, you can say on, which means

0:17:44.560000 --> 0:17:46.920000
 no dynamic negotiation.

0:17:46.920000 --> 0:17:48.560000
 Just force it to be on.

0:17:48.560000 --> 0:17:50.680000
 Or you could use any of those
 other ones we talked about.

0:17:50.680000 --> 0:17:55.020000
 Active and passive,
 desirable and auto.

0:17:55.020000 --> 0:17:58.900000
 Those are your options.

0:17:58.900000 --> 0:18:02.880000
 And then your command to see if it's actually
 working is show Ether channel

0:18:02.880000 --> 0:18:08.240000
 summary. Let's take a look at this for
 a moment and I'll do a quick example

0:18:08.240000 --> 0:18:32.980000
 of this. All right, so as this is coming
 up, we're going to just use,

0:18:32.980000 --> 0:18:37.060000
 we're just going to create
 a two port Ether channel.

0:18:37.060000 --> 0:19:07.740000
 Going to use switch one and switch
 two as my test bed here.

0:19:07.740000 --> 0:19:12.420000
 Okay, so we are good to go.

0:19:12.420000 --> 0:19:23.620000
 And just for demonstrative purposes,
 here is switch two.

0:19:23.620000 --> 0:19:25.440000
 Here is switch one.

0:19:25.440000 --> 0:19:29.120000
 They have two links that
 I'm going to use.

0:19:29.120000 --> 0:19:32.200000
 One link is gig one slash three.

0:19:32.200000 --> 0:19:36.420000
 The other link is gig
 two slash zero.

0:19:36.420000 --> 0:19:40.040000
 So that's what I'm going to
 form into an Ether channel.

0:19:40.040000 --> 0:19:44.860000
 So start out with show run.

0:19:44.860000 --> 0:19:48.400000
 And let's compare gig one three and
 two zero and make sure that they are

0:19:48.400000 --> 0:19:50.160000
 configured the same.

0:19:50.160000 --> 0:19:57.820000
 All right, so they're
 both trunking.

0:19:57.820000 --> 0:20:01.220000
 They're both desirable media
 type speed duplex is good.

0:20:01.220000 --> 0:20:04.140000
 So it looks like they're both
 the same on this side.

0:20:04.140000 --> 0:20:08.380000
 So these two interfaces I'm going to
 bundle together are ready to go.

0:20:08.380000 --> 0:20:11.320000
 Let's just check it now
 on the other side.

0:20:11.320000 --> 0:20:21.700000
 All right, and same thing
 that's good here.

0:20:21.700000 --> 0:20:23.320000
 They're both configured
 identically.

0:20:23.320000 --> 0:20:26.020000
 So I'll just start
 on this side here.

0:20:26.020000 --> 0:20:31.600000
 And for this, I'll use the
 port aggregation protocol.

0:20:31.600000 --> 0:20:36.160000
 Now, Cisco recommends that if you're
 going to use LACP or if you're going

0:20:36.160000 --> 0:20:42.580000
 to use PAGP, then really the
 keywords that you should use.

0:20:42.580000 --> 0:20:49.080000
 So if you're going to do PAGP, you
 should have desirable connecting to

0:20:49.080000 --> 0:20:52.720000
 desirable. They should both
 be desirable on both ends.

0:20:52.720000 --> 0:20:59.460000
 If you're doing LACP, then they should
 be active active on both sides.

0:20:59.460000 --> 0:21:03.640000
 So that's what I'm going to do
 to follow along with that.

0:21:03.640000 --> 0:21:22.500000
 Okay, so let's do com T interface
 range gig one slash three gig.

0:21:22.500000 --> 0:21:27.520000
 Two slash zero channel dash group.


0:21:27.520000 --> 0:21:30.820000
 You can see here on this platform, we
 have quite a large range of numbers

0:21:30.820000 --> 0:21:32.280000
 from one to two 55.

0:21:32.280000 --> 0:21:34.740000
 So I'll just say one mode.

0:21:34.740000 --> 0:21:36.940000
 I'm going to do a PAGP.

0:21:36.940000 --> 0:21:38.660000
 So I'll do desirable.

0:21:38.660000 --> 0:21:42.280000
 Now what you'll see is
 the moment I hit enter.

0:21:42.280000 --> 0:21:46.860000
 My logical port channel interface, which
 does not exist right now, will

0:21:46.860000 --> 0:21:48.020000
 be dynamically created.

0:21:48.020000 --> 0:21:52.160000
 And because I use channel group one,
 port channel one will be created

0:21:52.160000 --> 0:21:53.520000
 in the background.

0:21:53.520000 --> 0:21:55.260000
 And we'll see a syslog
 message about that.

0:21:55.260000 --> 0:21:58.240000
 See that creating a port channel
 interface port channel one.

0:21:58.240000 --> 0:22:03.100000
 All right, now the ether channel will
 not come up until I do the other

0:22:03.100000 --> 0:22:09.900000
 side. And we can confirm that by
 doing the command show ether.

0:22:09.900000 --> 0:22:13.100000
 Oh, type show ether.

0:22:13.100000 --> 0:22:15.440000
 Lord. Okay, come on.

0:22:15.440000 --> 0:22:20.900000
 Show ether channel summary.

0:22:20.900000 --> 0:22:24.720000
 So notice it now references
 my port channel.

0:22:24.720000 --> 0:22:28.640000
 It shows me what interfaces are part
 of it, but they both have a capital

0:22:28.640000 --> 0:22:32.560000
 I, which is what we can
 see means stand alone.

0:22:32.560000 --> 0:22:36.340000
 So these ports are not bundled at present
 because there's no negotiations

0:22:36.340000 --> 0:22:38.460000
 taking place with the other side.

0:22:38.460000 --> 0:22:42.040000
 So let's go ahead and do that.

0:22:42.040000 --> 0:22:51.560000
 Interface range gig one slash
 three gig two slash zero.

0:22:51.560000 --> 0:23:01.880000
 Channel dash group.

0:23:01.880000 --> 0:23:03.880000
 One mode desirable.

0:23:03.880000 --> 0:23:07.560000
 Creates my port channel interface.


0:23:07.560000 --> 0:23:11.400000
 And now if I wait long enough, we'll
 know the ether channel is up when

0:23:11.400000 --> 0:23:14.380000
 we see that the port channel
 changes state to up.

0:23:14.380000 --> 0:23:16.620000
 And that's what we see right here.


0:23:16.620000 --> 0:23:19.400000
 Port channel change state to up.

0:23:19.400000 --> 0:23:24.400000
 So now if I do show ether
 channel summary.

0:23:24.400000 --> 0:23:29.780000
 Notice that they have a capital P, which
 means they are now bundled into

0:23:29.780000 --> 0:23:30.900000
 the port channel.

0:23:30.900000 --> 0:23:32.800000
 Everything is good.

0:23:32.800000 --> 0:23:36.240000
 Now the last thing I want to show you
 now this goes above and beyond the

0:23:36.240000 --> 0:23:39.480000
 scope of the CCNA, but from a practical
 standpoint, you might want to

0:23:39.480000 --> 0:23:48.700000
 know this. This might not get you the
 variation you want across the links

0:23:48.700000 --> 0:23:49.460000
 of your either channel.

0:23:49.460000 --> 0:23:51.420000
 You might want to change
 it to something else.

0:23:51.420000 --> 0:23:53.140000
 Let me show you how
 to change that.

0:23:53.140000 --> 0:23:56.180000
 First of all, how do we verify what load
 balancing algorithm is currently

0:23:56.180000 --> 0:23:57.880000
 in effect. We can show it.

0:23:57.880000 --> 0:24:00.720000
 We can say show ether channel.

0:24:00.720000 --> 0:24:03.820000
 Load dash balance.

0:24:03.820000 --> 0:24:08.540000
 And see right now it says, okay.

0:24:08.540000 --> 0:24:10.900000
 Now this one's a little
 bit different.

0:24:10.900000 --> 0:24:13.140000
 That's because this
 is a virtual switch.

0:24:13.140000 --> 0:24:16.640000
 This virtual switch is already using
 source and destination IP address

0:24:16.640000 --> 0:24:22.560000
 for its load balancing algorithm.

0:24:22.560000 --> 0:24:25.720000
 Now I don't know if it will actually
 let me change that since this is

0:24:25.720000 --> 0:24:28.340000
 not a real physical
 hardware switch.

0:24:28.340000 --> 0:24:35.880000
 The way you would change it is port
 dash channel load dash balance.

0:24:35.880000 --> 0:24:38.160000
 Okay, good. We can change it.

0:24:38.160000 --> 0:24:42.140000
 So most of the time what I've seen
 is that source Mac is the default,

0:24:42.140000 --> 0:24:44.120000
 which would have shown
 up right here.

0:24:44.120000 --> 0:24:47.240000
 But regardless of what you see up here,
 if you want to change it to something

0:24:47.240000 --> 0:24:51.160000
 else, this is your command to do so
 at the global configuration level.

0:24:51.160000 --> 0:25:05.100000
 Notice this is this is not done
 on a unique ether channel.

0:25:05.100000 --> 0:25:09.480000
 Can't do that. If you're going to change
 it, it's an all or nothing deal.

0:25:09.480000 --> 0:25:12.860000
 So here at the global level, we could change
 it to destination IP, destination

0:25:12.860000 --> 0:25:17.600000
 Mac, all sorts of things
 in this list.

0:25:17.600000 --> 0:25:22.080000
 And that is how you
 would complete that.

0:25:22.080000 --> 0:25:27.120000
 So that completes our discussion
 on a review of ether channel.

0:25:27.120000 --> 0:25:28.440000
 And I hope you found it useful.