WEBVTT

1
00:00.000 --> 00:05.140
Well, the age-old problem in the Layer 2 space is that if I want to connect

2
00:05.140 --> 00:05.420
these two

3
00:05.420 --> 00:09.080
switches together and maybe I've got a fiber connection between them, and I say

4
00:09.080 --> 00:09.440
, "Hey,

5
00:09.440 --> 00:10.840
I would like some redundancy.

6
00:10.840 --> 00:14.650
I don't want that one connection going down and breaking the connection between

7
00:14.650 --> 00:15.320
switches."

8
00:15.320 --> 00:19.540
As soon as I add that second link, we are going to see Spanning Tree kick into

9
00:19.540 --> 00:19.940
gear

10
00:19.940 --> 00:22.320
because we have to prevent the broadcast loops.

11
00:22.320 --> 00:26.480
I don't want an endless loop of traffic happening here with each broadcast

12
00:26.480 --> 00:27.760
frame and flooded

13
00:27.760 --> 00:31.220
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

13
00:27.760 --> 00:31.220
frame for that matter, and so Spanning Tree is going to do its job between to

14
00:31.220 --> 00:31.800
block one

15
00:31.800 --> 00:36.040
of the sides of these links, and now we have prevented the loop.

16
00:36.040 --> 00:38.760
And so, yeah, it's great that we have loop prevention.

17
00:38.760 --> 00:41.400
There's not going to be any loops.

18
00:41.400 --> 00:45.480
But for that matter, we actually do have the redundancy.

19
00:45.480 --> 00:50.090
If one of these links goes down, Spanning Tree will remove the block and allow

20
00:50.090 --> 00:50.320
us to

21
00:50.320 --> 00:52.120
communicate on this.

22
00:52.120 --> 00:56.730
And so, life is good, but it's not as good as it could be because we're wasting

23
00:56.730 --> 00:57.280
a whole

24
00:57.280 --> 00:59.160
lot of bandwidth here.

25
00:59.160 --> 01:03.880
Imagine these are expensive, maybe in the modern network, expensive 10-gig
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

25
00:59.160 --> 01:03.880
Imagine these are expensive, maybe in the modern network, expensive 10-gig

26
01:03.880 --> 01:04.520
links.

27
01:04.520 --> 01:09.260
And so, I paid all this money for 10-gig transceivers and 10-gig quality fiber

28
01:09.260 --> 01:09.840
between

29
01:09.840 --> 01:13.630
the two, 10-gig ports on the switches for that matter, and I'm sitting here

30
01:13.630 --> 01:14.120
with a total

31
01:14.120 --> 01:19.130
of 10-gig of throughput, even though I purchased enough hardware to have 20-gig

32
01:19.130 --> 01:20.240
of throughput.

33
01:20.240 --> 01:25.630
And so, this is going to be where we head for the conversations around our

34
01:25.630 --> 01:27.240
ether channels.

35
01:27.240 --> 01:30.400
And there are a lot of conversations to be had.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

35
01:27.240 --> 01:30.400
And there are a lot of conversations to be had.

36
01:30.400 --> 01:34.640
But the ether channel is an interesting concept.

37
01:34.640 --> 01:39.520
The idea here is that we will create a bundle of physical links.

38
01:39.520 --> 01:43.240
So the bundle is on the physical level.

39
01:43.240 --> 01:46.640
But logically, we have a single link.

40
01:46.640 --> 01:51.120
It's one logical layer two connection.

41
01:51.120 --> 01:55.070
And so, at this point, what we can do is we can bundle these two connections

42
01:55.070 --> 01:56.080
together.

43
01:56.080 --> 02:00.760
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

43
01:56.080 --> 02:00.760
And now, from a layer two perspective, this is treated as if it's one link.

44
02:00.760 --> 02:02.760
Spanning tree is going to view this as one link.

45
02:02.760 --> 02:06.040
Our broadcasts are going to view this as one link.

46
02:06.040 --> 02:09.520
So for example, if a broadcast packet comes into this switch, and we know that

47
02:09.520 --> 02:09.960
we need

48
02:09.960 --> 02:13.850
to send a broadcast frame out every single interface on that switch, well, we

49
02:13.850 --> 02:14.400
're going

50
02:14.400 --> 02:16.440
to pick one of these and send it out.

51
02:16.440 --> 02:18.560
We're not going to send it out the other one.

52
02:18.560 --> 02:21.790
Because by sending it out the one physical link, we've satisfied our

53
02:21.790 --> 02:22.880
requirement to send

54
02:22.880 --> 02:29.360
that broadcast frame out that single logical layer two connection.

55
02:29.360 --> 02:35.020
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

55
02:29.360 --> 02:35.020
Now it is worth noting that we can also form a single logical layer three

56
02:35.020 --> 02:36.360
connection.

57
02:36.360 --> 02:38.360
But that's not the scope of this conversation.

58
02:38.360 --> 02:41.880
We're going to be focusing in on layer two ether channels.

59
02:41.880 --> 02:46.180
And for, I guess, as far as layer three is concerned, we don't really see that

60
02:46.180 --> 02:46.600
a whole

61
02:46.600 --> 02:48.440
lot in the real world.

62
02:48.440 --> 02:52.790
Because when it comes to layer three, routing handles many different links

63
02:52.790 --> 02:53.760
pretty well.

64
02:53.760 --> 02:56.400
There's the equal cost of multi-pathing concept.

65
02:56.400 --> 03:00.140
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

65
02:56.400 --> 03:00.140
And so I can just take two layer three links and yeah, I could bundle them

66
03:00.140 --> 03:00.880
together or

67
03:00.880 --> 03:04.320
I could just leave them separate and effectively get the same result.

68
03:04.320 --> 03:07.420
And so we don't see a lot of logical layer three links unless we need to save

69
03:07.420 --> 03:08.160
on IP addresses

70
03:08.160 --> 03:10.000
or something along those lines.

71
03:10.000 --> 03:14.560
For the most part, ether channels are more heavily used in the layer two space.

72
03:14.560 --> 03:17.160
But it is possible to turn them into layer three.

73
03:17.160 --> 03:19.160
So keep that in mind.

74
03:19.160 --> 03:24.210
Now when we're bundling ether channel connections, we can have up to eight

75
03:24.210 --> 03:25.200
connections in iOS

76
03:25.200 --> 03:26.520
XE.

77
03:26.520 --> 03:29.680
There are other platforms that actually do support more than this.

78
03:29.680 --> 03:33.300
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

78
03:29.680 --> 03:33.300
But we can support up to eight, meaning that now, if I just draw this again

79
03:33.300 --> 03:33.880
over here,

80
03:33.880 --> 03:37.290
now I could have one, two, three, four, five, six, seven, we'll squeeze an

81
03:37.290 --> 03:39.040
eighth over here.

82
03:39.040 --> 03:41.360
And we've got eight connections between these two switches.

83
03:41.360 --> 03:44.080
We can bundle all of these together.

84
03:44.080 --> 03:47.230
And so rather than only having one active connection and seven that are just

85
03:47.230 --> 03:47.640
sitting

86
03:47.640 --> 03:50.960
there idle, now all eight of these are active.

87
03:50.960 --> 03:56.210
Furthermore, if we're using a dynamic protocol like LACP, we can actually have

88
03:56.210 --> 03:57.520
eight additional

89
03:57.520 --> 04:02.620
ports in standby operation, which is incredible because now we're talking about
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

89
03:57.520 --> 04:02.620
ports in standby operation, which is incredible because now we're talking about

90
04:02.620 --> 04:03.560
an extra eight.

91
04:03.560 --> 04:06.320
So one, two, three, four, five, six, seven, eight.

92
04:06.320 --> 04:09.360
So 16 total where yeah, eight are active.

93
04:09.360 --> 04:10.360
These are 10 gig links.

94
04:10.360 --> 04:15.170
We'd have 80 gig of total throughput, but if one of those active links goes

95
04:15.170 --> 04:15.920
down, one

96
04:15.920 --> 04:19.800
of these standby links will be inserted into the, into the bundle.

97
04:19.800 --> 04:21.880
And so maybe we don't have eight standbys.

98
04:21.880 --> 04:25.310
Maybe we just have a couple of them just in case, but either way, we've got a

99
04:25.310 --> 04:26.800
lot of flexibility

100
04:26.800 --> 04:30.640
for establishing these ether channels.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

100
04:26.800 --> 04:30.640
for establishing these ether channels.

101
04:30.640 --> 04:33.640
Now importantly, the link types are going to matter here.

102
04:33.640 --> 04:37.520
The link types must match.

103
04:37.520 --> 04:40.400
We're talking about matching these links.

104
04:40.400 --> 04:42.120
This happens on two levels.

105
04:42.120 --> 04:45.590
First of all, we have to worry about the media type, meaning that I can't

106
04:45.590 --> 04:46.480
bundle copper and

107
04:46.480 --> 04:47.480
fiber together.

108
04:47.480 --> 04:48.720
It just doesn't work.

109
04:48.720 --> 04:52.040
And furthermore, I also have to match the speeds.

110
04:52.040 --> 04:56.120
So I can't bundle, for example, one and 10 gig connections.

111
04:56.120 --> 05:00.360
This isn't an option in the same way that copper and fiber.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

111
04:56.120 --> 05:00.360
This isn't an option in the same way that copper and fiber.

112
05:00.360 --> 05:02.280
This wouldn't be an option either.

113
05:02.280 --> 05:03.360
So we can't mix and match.

114
05:03.360 --> 05:07.300
We just simply have to have up to eight connections, or again, however many

115
05:07.300 --> 05:08.880
standbys we want, that

116
05:08.880 --> 05:12.640
match on both the media type and the speed.

117
05:12.640 --> 05:16.690
Now an interesting part of this conversation actually has to do with the names

118
05:16.690 --> 05:17.160
that we

119
05:17.160 --> 05:20.920
use when we're calling these bundles something.

120
05:20.920 --> 05:23.400
For example, I've got ether channel written here.

121
05:23.400 --> 05:26.880
And typically, this is what Cisco likes to use when talking about them.

122
05:26.880 --> 05:32.280
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

122
05:26.880 --> 05:32.280
But believe it or not, an ether channel, this is actually a Cisco term.

123
05:32.280 --> 05:34.000
Somebody else calls them ether channels.

124
05:34.000 --> 05:36.400
This is something that Cisco came up with.

125
05:36.400 --> 05:42.840
From an industry standard perspective, we typically refer to these as port

126
05:42.840 --> 05:44.000
channels.

127
05:44.000 --> 05:47.880
And this is a term that's used even on some of Cisco's platforms.

128
05:47.880 --> 05:52.900
For example, on the Nexus platforms that are inside of the data center, Cisco

129
05:52.900 --> 05:53.360
tried

130
05:53.360 --> 05:59.040
to get away from any Cisco nomenclature, or at least as much as possible.

131
05:59.040 --> 06:03.040
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

131
05:59.040 --> 06:03.040
They even shut off a lot of Cisco protocols that are no longer used.

132
06:03.040 --> 06:08.980
And so same thing here when they put together Nexus, they decided to call these

133
06:08.980 --> 06:10.280
port channels.

134
06:10.280 --> 06:14.920
And yes, this does impact our show commands that are configuration commands.

135
06:14.920 --> 06:18.560
For example, on iOS X E.

136
06:18.560 --> 06:23.180
iOS X E, we're going to have a really well known configuration command that we

137
06:23.180 --> 06:23.600
want to

138
06:23.600 --> 06:27.160
run, which is show ether channel summary.

139
06:27.160 --> 06:29.440
This is a really great command.

140
06:29.440 --> 06:31.560
It tells us a lot of what's happening.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

140
06:29.440 --> 06:31.560
It tells us a lot of what's happening.

141
06:31.560 --> 06:35.040
And we'll see this later on when we're configuring ether channels.

142
06:35.040 --> 06:39.440
But in NXOS, which is running on Nexus, we don't do show ether channel summary.

143
06:39.440 --> 06:42.040
We do show port channel summary.

144
06:42.040 --> 06:44.400
And yeah, there's a hyphen in there.

145
06:44.400 --> 06:48.160
So that is a little bit of a syntax nuance.

146
06:48.160 --> 06:51.260
And this might show up in other platforms as well, especially for getting our

147
06:51.260 --> 06:52.080
hands on

148
06:52.080 --> 06:53.480
non-Cisco gear.

149
06:53.480 --> 06:54.480
So keep that in mind.

150
06:54.480 --> 06:57.980
And though I know for me growing up in the Cisco world, I only ever call these

151
06:57.980 --> 06:59.400
ether channels.

152
06:59.400 --> 07:01.920
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

152
06:59.400 --> 07:01.920
And then to see them all of a sudden being called port channels in a lot of

153
07:01.920 --> 07:02.400
different

154
07:02.400 --> 07:03.400
capacities.

155
07:03.400 --> 07:06.240
That was a little bit of a surprise for me.

156
07:06.240 --> 07:08.600
Now there are other names as well.

157
07:08.600 --> 07:15.320
For example, on the server side of things, we call this Nick teaming because

158
07:15.320 --> 07:15.800
from the

159
07:15.800 --> 07:17.640
server's perspective, that's what we're doing.

160
07:17.640 --> 07:20.840
We're taking a server and we have a couple of nicks in here.

161
07:20.840 --> 07:25.880
And so we pull them up to a local switch and then we can bundle these together.

162
07:25.880 --> 07:29.600
So we might refer to this as an ether channel or a port channel.

163
07:29.600 --> 07:34.080
And the server team is going to call this that Nick team.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

163
07:29.600 --> 07:34.080
And the server team is going to call this that Nick team.

164
07:34.080 --> 07:36.040
So be aware that that term exists.

165
07:36.040 --> 07:40.820
And lastly, another term that Cisco does like to use in a lot of other industry

166
07:40.820 --> 07:41.120
, the

167
07:41.120 --> 07:45.280
manufacturers do as well, is the concept of the lag.

168
07:45.280 --> 07:51.280
The lag stands for link aggregation.

169
07:51.280 --> 07:55.440
And we just take the L and the AG there, we call it a lag.

170
07:55.440 --> 07:59.790
And no different than any of these other concepts here, they all mean the same

171
07:59.790 --> 08:00.520
thing.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

171
07:59.790 --> 08:00.520
thing.

172
08:00.520 --> 08:05.460
But Cisco is especially going to use this lag term as far as their wireless LAN

173
08:05.460 --> 08:06.400
controllers

174
08:06.400 --> 08:09.120
and especially their legacy wireless LAN controllers.

175
08:09.120 --> 08:12.680
But it's still used in wireless vernacular today.

176
08:12.680 --> 08:16.880
Even from a Cisco perspective, where Cisco clearly likes to use a lot of

177
08:16.880 --> 08:18.000
different terms,

178
08:18.000 --> 08:23.630
not just the ether channel term that they created, but also port channels and l

179
08:23.630 --> 08:24.000
ags.

180
08:24.000 --> 08:27.670
And it just, no matter which term we see, it's all referring to the same

181
08:27.670 --> 08:28.400
concept and

182
08:28.400 --> 08:31.240
that's the primary takeaway here.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

182
08:28.400 --> 08:31.240
that's the primary takeaway here.

183
08:31.240 --> 08:37.030
Now there are also on top of all of this different modes of running our port

184
08:37.030 --> 08:38.240
channels or ether

185
08:38.240 --> 08:40.280
channels in.

186
08:40.280 --> 08:45.110
And typically, in a lot of cases, we're going to see one of a couple modes,

187
08:45.110 --> 08:46.240
either a static

188
08:46.240 --> 08:51.660
mode of operation where I hard set this and I say, hey, these eight ports, you

189
08:51.660 --> 08:52.200
guys are

190
08:52.200 --> 08:57.280
in a port channel and you ports down here, you're in a port channel.

191
08:57.280 --> 09:00.880
And I hard map this, I statically configure this.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

191
08:57.280 --> 09:00.880
And I hard map this, I statically configure this.

192
09:00.880 --> 09:04.730
This is going to have some amount of parallels to the trunk operation that we

193
09:04.730 --> 09:05.440
just talked

194
09:05.440 --> 09:11.660
about because with trunks, I could configure it statically or I could configure

195
09:11.660 --> 09:12.960
it dynamically.

196
09:12.960 --> 09:18.560
And if we're doing it dynamically, this is going to rely on negotiation.

197
09:18.560 --> 09:21.200
So again, just like we just talked about, if you're working your way through

198
09:21.200 --> 09:21.760
this course

199
09:21.760 --> 09:25.070
sequentially, we just looked at ethernet trunks and the fact that we can

200
09:25.070 --> 09:26.320
dynamically negotiate

201
09:26.320 --> 09:29.000
trunk links, we can do the same thing here.

202
09:29.000 --> 09:33.990
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

202
09:29.000 --> 09:33.990
So this is a great way to try to prevent misconfiguration, because let's say I

203
09:33.990 --> 09:34.400
just

204
09:34.400 --> 09:41.000
have four links and I properly configure the first three ports.

205
09:41.000 --> 09:45.550
But on this last one, I say, hey, you are in a port channel, but I forget to

206
09:45.550 --> 09:46.320
configure

207
09:46.320 --> 09:47.720
it on this side.

208
09:47.720 --> 09:52.680
Well this creates a really awkward situation because the top switch is bundling

209
09:52.680 --> 09:53.400
three, four

210
09:53.400 --> 09:57.640
connections and the bottom switch is only bundling three connections.

211
09:57.640 --> 10:01.990
This is a huge mistake and can create loops or otherwise create inconsistent
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

211
09:57.640 --> 10:01.990
This is a huge mistake and can create loops or otherwise create inconsistent

212
10:01.990 --> 10:03.280
traffic flows

213
10:03.280 --> 10:06.520
and we want to avoid this at all cost.

214
10:06.520 --> 10:10.200
But if I'm statically configuring it, there's nothing on the switches that will

215
10:10.200 --> 10:10.760
recognize

216
10:10.760 --> 10:12.400
that this is happening.

217
10:12.400 --> 10:19.970
Instead, I can use dynamic negotiation and I can tell all of these ports to try

218
10:19.970 --> 10:21.360
to negotiate

219
10:21.360 --> 10:22.600
a port channel.

220
10:22.600 --> 10:26.780
So what happens again if I properly configure it on all four of these ports up

221
10:26.780 --> 10:27.400
top, but

222
10:27.400 --> 10:30.880
I accidentally only put it on three on the bottom.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

222
10:27.400 --> 10:30.880
I accidentally only put it on three on the bottom.

223
10:30.880 --> 10:34.450
Well at this point, the negotiation is going to work for three of these

224
10:34.450 --> 10:35.360
connections and

225
10:35.360 --> 10:39.560
even though the top switch is trying to negotiate adding this link into the

226
10:39.560 --> 10:40.480
bundle, the other

227
10:40.480 --> 10:42.880
side is not going to respond.

228
10:42.880 --> 10:47.720
And so we actually properly only bundle three of these connections together.

229
10:47.720 --> 10:53.370
So there's a lot of advantage to using a dynamic protocol, not the least of

230
10:53.370 --> 10:55.000
which is the fact

231
10:55.000 --> 10:59.250
that now we can take advantage of, well, yeah, the active and standby

232
10:59.250 --> 11:00.200
methodology.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

232
10:59.250 --> 11:00.200
methodology.

233
11:00.200 --> 11:02.600
This requires dynamic configuration.

234
11:02.600 --> 11:04.760
I can't do that in the static world.

235
11:04.760 --> 11:10.590
So again, this helps us with consistent configuration and it helps us by

236
11:10.590 --> 11:15.320
delivering the standby concept.

237
11:15.320 --> 11:19.370
Now there are two protocols that we can use for dynamic ether channel

238
11:19.370 --> 11:20.600
configuration.

239
11:20.600 --> 11:24.970
The first is the industry standard LACP, which is pretty much what we use today

240
11:24.970 --> 11:25.160
.

241
11:25.160 --> 11:31.610
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

241
11:25.160 --> 11:31.610
And then we also have Cisco's version, which is port aggregation protocol, PAGP

242
11:31.610 --> 11:31.680
.

243
11:31.680 --> 11:37.260
Now even though iOS XE continues to support PAGP, Cisco has disabled it on

244
11:37.260 --> 11:38.720
other platforms.

245
11:38.720 --> 11:42.200
For example, Nexus doesn't support PAGP.

246
11:42.200 --> 11:46.320
And generally speaking, we're going to see that we just like to use LACP.

247
11:46.320 --> 11:49.450
So it's again, there's a lot of parallels between ether channels and trunks as

248
11:49.450 --> 11:50.080
far as

249
11:50.080 --> 11:56.200
iOS XE is concerned, because even though Cisco supported ISL for a long time,

250
11:56.200 --> 11:57.080
they eventually

251
11:57.080 --> 11:59.360
got rid of it because nobody was using it.

252
11:59.360 --> 12:04.120
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

252
11:59.360 --> 12:04.120
Meanwhile, PAGP, they do still support, but nobody really uses it for the most

253
12:04.120 --> 12:04.600
part.

254
12:04.600 --> 12:11.200
We're primarily relying on LACP, but it was the port aggregation protocol.

255
12:11.200 --> 12:12.400
The name is right there.

256
12:12.400 --> 12:16.330
It was the protocol that Cisco supported before the industry had an option,

257
12:16.330 --> 12:16.880
which again is

258
12:16.880 --> 12:17.880
LACP.

259
12:17.880 --> 12:19.560
So here's our industry standard.

260
12:19.560 --> 12:21.120
Here's our Cisco flavor.

261
12:21.120 --> 12:23.520
And in the real world, we're usually going to see LACP.

262
12:23.520 --> 12:33.520
[BLANK_AUDIO]