WEBVTT

0:00:05.260000 --> 0:00:08.940000
 Now, last video we looked at what an
 Ethernet frame looks like in the

0:00:08.940000 --> 0:00:12.860000
 various frames or I should say the various
 fields within that frame, what

0:00:12.860000 --> 0:00:14.800000
 their names were and what
 they were used for.

0:00:14.800000 --> 0:00:18.260000
 And I talked a little bit about the minimum
 and maximum sizes of an Ethernet

0:00:18.260000 --> 0:00:21.320000
 frame. I'd like to talk a little
 bit more about that now.

0:00:21.320000 --> 0:00:27.580000
 So there are terms for Ethernet frames
 that fall outside of the scope

0:00:27.580000 --> 0:00:31.280000
 of a minimum size in
 a maximum size frame.

0:00:31.280000 --> 0:00:34.400000
 And when you see something like that,
 this is generally indicative of

0:00:34.400000 --> 0:00:36.600000
 some kind of an error.

0:00:36.600000 --> 0:00:38.520000
 So let's talk about a Runt.

0:00:38.520000 --> 0:00:43.000000
 A Runt is any Ethernet frame that
 is less than the minimum MTU.

0:00:43.000000 --> 0:00:46.100000
 So MTU stands for maximum
 transmission unit.

0:00:46.100000 --> 0:00:49.080000
 Maximum transmission unit is
 the largest a frame could be.

0:00:49.080000 --> 0:00:54.360000
 Now we said that Ethernet said that
 the data of a frame could be no less

0:00:54.360000 --> 0:00:59.080000
 than 46 bytes. And then when you add
 on, for example, the source address,

0:00:59.080000 --> 0:01:02.980000
 the destination address, and the FCS
 field, the entire Ethernet frame,

0:01:02.980000 --> 0:01:08.280000
 the smallest of frame could ever
 be would be 64 bytes total.

0:01:08.280000 --> 0:01:13.300000
 So if an Ethernet NIC card ever sees
 an incoming frame and says, hmm,

0:01:13.300000 --> 0:01:15.360000
 it just stopped.

0:01:15.360000 --> 0:01:20.400000
 No more bits coming in, but I only
 got enough bits that were 35 bytes

0:01:20.400000 --> 0:01:25.920000
 or 50 bytes. You'll say,
 that's too short.

0:01:25.920000 --> 0:01:29.680000
 That frame at minimum should have been
 64 bytes long and that is considered

0:01:29.680000 --> 0:01:32.700000
 a Runt. So that frame
 will be discarded.

0:01:32.700000 --> 0:01:36.900000
 It did not meet the legal minimum
 size of an Ethernet frame.

0:01:36.900000 --> 0:01:40.280000
 As it says here, that's typically caused
 by collisions, malfunctioning

0:01:40.280000 --> 0:01:42.700000
 nicks or software issues.

0:01:42.700000 --> 0:01:44.480000
 And then just the opposite.

0:01:44.480000 --> 0:01:47.780000
 Any frame that's larger
 than 15, 18 bytes.

0:01:47.780000 --> 0:01:52.920000
 So once again, 1500 of data and then 18
 bytes when you add in the destination

0:01:52.920000 --> 0:01:57.920000
 Mac, source Mac, and FCS field
 that adds up to 18 bytes.

0:01:57.920000 --> 0:02:02.420000
 So a regular Ethernet frame should not
 be any larger than 15, 18 bytes.

0:02:02.420000 --> 0:02:06.700000
 If it is, that will be excessively large
 and that will be called what's

0:02:06.700000 --> 0:02:11.140000
 called a giant. And the giant frame will
 be discarded because that's also

0:02:11.140000 --> 0:02:15.980000
 an error. Also typically generate
 by malfunctioning nicks cards.

0:02:15.980000 --> 0:02:19.480000
 Or possibly you've got something called
 jumbo frames configured on one

0:02:19.480000 --> 0:02:21.320000
 side but not on the other side.

0:02:21.320000 --> 0:02:24.900000
 So we'll get into jumbo frames
 here in just one second.

0:02:24.900000 --> 0:02:31.660000
 Now if you're familiar with LAN switching,
 you're familiar with 802.1Q

0:02:31.660000 --> 0:02:38.360000
 tags. You know that an 802.1Q tag adds
 an extra four bytes to something.

0:02:38.360000 --> 0:02:43.180000
 So if I have two switches connected end
 to end and they're both configured

0:02:43.180000 --> 0:02:48.700000
 for 802.1Q, they will actually accept
 frames up to 15, 22 bytes.

0:02:48.700000 --> 0:02:52.380000
 They'll say, okay, a maximum Ethernet
 frame would be 15, 18, but there's

0:02:52.380000 --> 0:02:56.320000
 going to be an additional four byte
 tag in there, which will bump it up

0:02:56.320000 --> 0:03:00.760000
 to 15, 22. Technically we
 call that a baby giant.

0:03:00.760000 --> 0:03:04.460000
 A baby giant is something that's slightly
 larger than a maximum sized

0:03:04.460000 --> 0:03:06.500000
 Ethernet frame and
 that will be okay.

0:03:06.500000 --> 0:03:08.440000
 That will be acceptable.

0:03:08.440000 --> 0:03:10.320000
 Now what if we had this scenario?

0:03:10.320000 --> 0:03:18.600000
 So my upper layer data, whatever it
 is, has sent down to TCP, let's say,

0:03:18.600000 --> 0:03:22.960000
 8,760 bytes of data.

0:03:22.960000 --> 0:03:25.220000
 So what would TCP do with that?

0:03:25.220000 --> 0:03:28.760000
 Well there is some interaction between
 layer two, layer three and layer

0:03:28.760000 --> 0:03:35.360000
 four to where TCP up at layer four will
 recognize, okay, I can't put this

0:03:35.360000 --> 0:03:36.480000
 into a single TCP system.

0:03:36.480000 --> 0:03:39.880000
 So we have a big segment because if I do,
 it'll be too large for the Ethernet

0:03:39.880000 --> 0:03:44.300000
 frame. The Ethernet frame can
 only have 1500 bytes of data.

0:03:44.300000 --> 0:03:49.160000
 So what TCP would do is it would break
 that into six different segments

0:03:49.160000 --> 0:03:52.460000
 of 14, 60 bytes each.

0:03:52.460000 --> 0:03:56.040000
 It would add the TCP header and
 you'd have the IP header.

0:03:56.040000 --> 0:04:01.480000
 And that would end up resulting in
 six maximum sized Ethernet frames.

0:04:01.480000 --> 0:04:06.000000
 So that one chunk, that one block of
 data resulted in six Ethernet frames

0:04:06.000000 --> 0:04:09.980000
 and each frame you can see here is spaced
 with the interframe gap in the

0:04:09.980000 --> 0:04:13.940000
 middle of them. Well what if I have a
 scenario where I've got two servers

0:04:13.940000 --> 0:04:19.060000
 that need to communicate and these servers
 are doing massive data backup.

0:04:19.060000 --> 0:04:22.940000
 Maybe they're connected via like a
 gig link that's super fast and they

0:04:22.940000 --> 0:04:27.220000
 just have to slam each other with
 data, massive data transfers.

0:04:27.220000 --> 0:04:32.900000
 Well this will work but wouldn't it be
 more efficient if I could actually

0:04:32.900000 --> 0:04:37.920000
 create one Ethernet frame that
 contained all of that.

0:04:37.920000 --> 0:04:41.220000
 And that's what's called
 a jumbo frame.

0:04:41.220000 --> 0:04:45.420000
 So jumbo frames are not supported by
 default but if you have the hardware,

0:04:45.420000 --> 0:04:50.100000
 for example if the adapter on your knit
 card supports it, if your adapters

0:04:50.100000 --> 0:04:54.640000
 on your switch interfaces and your router
 interfaces support it, you can

0:04:54.640000 --> 0:04:58.300000
 actually configure all these things to
 support Ethernet frames are larger

0:04:58.300000 --> 0:05:01.020000
 than the maximum size.

0:05:01.020000 --> 0:05:04.960000
 Now the actual size of a jumbo frame
 is variable, it really depends on

0:05:04.960000 --> 0:05:06.420000
 what hardware you're
 talking about.

0:05:06.420000 --> 0:05:12.080000
 For example Cisco Nexus switches, support
 jumbo frames are up to 9,216

0:05:12.080000 --> 0:05:15.840000
 bytes long. That's really large.

0:05:15.840000 --> 0:05:19.620000
 Whereas some of the older work group
 switches from Cisco only support

0:05:19.620000 --> 0:05:22.240000
 jumbo frames up to 2,000 bytes.

0:05:22.240000 --> 0:05:23.720000
 So pretty big difference.

0:05:23.720000 --> 0:05:27.480000
 So you'll want to find out if there's
 any device along the path that does

0:05:27.480000 --> 0:05:29.260000
 not support jumbo
 frames, that's it.

0:05:29.260000 --> 0:05:30.880000
 You can't do it.

0:05:30.880000 --> 0:05:36.660000
 So all the devices end to end between
 these two servers in my example,

0:05:36.660000 --> 0:05:40.400000
 including the servers themselves, would
 have to support jumbo frames in

0:05:40.400000 --> 0:05:42.260000
 order to take advantage of this.

0:05:42.260000 --> 0:05:46.080000
 And you want to make sure that they all
 support the same size or at least

0:05:46.080000 --> 0:05:48.720000
 set it to a size that
 is supported.

0:05:48.720000 --> 0:05:50.420000
 Here you can see the
 command on a switch.

0:05:50.420000 --> 0:05:56.920000
 This is on a 3560 switch to
 enable it for jumbo frames.

0:05:56.920000 --> 0:06:00.940000
 And here I've also included a screenshot
 taken from a Windows 10 laptop

0:06:00.940000 --> 0:06:03.740000
 of how you can enable
 jumbo frames on that.

0:06:03.740000 --> 0:06:06.420000
 Typically you would not
 do this on a laptop.

0:06:06.420000 --> 0:06:09.440000
 You're not really going to get any benefit
 on a laptop because most likely

0:06:09.440000 --> 0:06:13.760000
 the switch you're connected to or your
 default gateway does not support

0:06:13.760000 --> 0:06:16.720000
 jumbo frames. So that's why I said
 usually jumbo frames are something

0:06:16.720000 --> 0:06:21.180000
 that are enabled end to end between
 like server connections.

0:06:21.180000 --> 0:06:23.800000
 So that concludes this
 particular section.

0:06:23.800000 --> 0:06:27.280000
 In the next and the last video for this
 series, we'll go into the different

0:06:27.280000 --> 0:06:28.940000
 types of Ethernet cabling.