- Next let's talk about the Ethernet II frame. Now understanding all the pieces of the Ethernet II frame are
- going to be critical for your understanding of how networking operates, specifically it will enhance your
- ability to understand and troubleshoot how Ethernet networks operate.
- We're going to base this conversation on moving a frame from one device on the network to another device on the network.
- So we'll move a frame from a device on the left to a device on the right and that will be the context of this conversation.
- Now if we remember back from our discussion about encapsulation,
- with encapsulation we had this layer 3 network packet, right, and that packet contained all kinds of
- information, including that chunk of a website we are trying to send from one device to another.
- We call that our packet. It was a chunk of data with a network layer header.
- Here we're using IP as our header information. What we're going to do next is we're going to stick that
- packet inside of our data link layer frame. Now we have our frame here, frame was just a chunk of data with
- the data link layer header here. Here I have an Ethernet layer on it, let's go do a deep dive into that Ethernet header.
- So, here is an Ethernet II frame. Ethernet II frame consists of a destination MAC address first,
- a source MAC address second, a type field as the third one, then we have our data packet, this is our layer 3
- or other information that the stuff we're carrying in the frame, that's our data packet, that can be a
- maximum of 1500 bytes in an Ethernet II frame, and then we follow that up by something called the FCS,
- which is the frame check sequence, and it's there to make sure the frame arrives at the destination with integrity.
- I'll show you exactly how that works in just a bit. But first let's start with our destination MAC address.
- So if you take a look at what that MAC address consists of, that MAC address consists of several pieces.
- That MAC address is assigned to you by the IEEE, so when you purchase a license for Ethernet, they give you
- a manufacturer ID number, which is the first 24 bits of the 48 bit MAC address.
- What I've shown you here is I've divided up my MAC address into two components.
- The middle one is written in hexadecimal, which is the traditional method for writing out a MAC address.
- Right below it, though, I've done the binary conversions so you can see that the first 24 bits are the
- manufacturer IDs, and then the last 24 bits are reserved for the manufacturer to provide a unique serial
- number for each piece of equipment they produce. Are all MAC addresses unique?
- In theory, yes. In production, no. I have encountered more than one situation where I've been in a room of
- equipment and more than one device has the same MAC address as another device, and that causes very bizarre
- behavior on a network, and usually it causes issues with both devices communicating, makes it difficult to
- troubleshoot because it's such a rare issue, and we don't expect that the system for deploying MAC addresses
- will ever create a duplicate. But it happens. Regardless, our MAC address is 48 bits long.
- We can always tell who manufactured that MAC address by looking at the first 24 bits.
- We can actually do a lookup on Google of a MAC address to find out who manufactured it.
- Last number, like I said, is that serial number. We use that to identify the unique hosts on our network.
- The source MAC address is going to be exact same format here. The difference between the two is the
- destination MAC address is going to be the MAC address where the frame is going to be sent to.
- The source MAC address is the MAC address of the workstation that I'm sending the frame from.
- All right, next let's go on and take a look at that type field. Now, the type field is a 16 bit field,
- and what we use that for is to identify type of message being carried in the frame.
- It's effectively identifying the layer 3 protocol we're using, but not always.
- If the packet that we're carrying in the frame is an IP version 4 packet, the type field will have 16 bits
- of 0000 1000 0000 0000. That translates to effectively a hexadecimal value of 0 8 0 0.
- So, when we're looking at this value typically when we're capturing this traffic or examining frames,
- we're going to look at it in the hexadecimal values just to make our brains a little bit happier,
- so IP version 4 ends up being 0800. As with most hexadecimal values, we indicate that it's hexadecimal and
- not some other format by putting a 0x in front of the number. So, IPv4 here, 0x0800.
- If we're using IPv6, the type field there would have a value of 0x86DD.
- If it's an ARP message, our ARP message is 0x0806. We're going to talk about ARP a little bit later in this
- course, and we'll talk about ARP a lot more throughout the entire series here, because understanding ARP will
- help you understand networks entirely. I was just at the Cisco Live conference, I was talking with many,
- many engineers, and a lot of them, even the CCIEs will ask people who they're interviewing for work to just
- simply describe how ARP works and why it's needed, so we're going to cover that in as much detail as we
- can so that you can leave this course and go impress people with your knowledge of ARP operation.
- The type field is just going to identify that layer 3 information that's being carried,
- and we filled that in to that 16 bit section, whatever value that is that identifies that packet type.
- The last piece here is that frame check sequence. Now that frame check sequence field, what we're going to
- do there is we're going to put the value of the calculation called a cyclical redundancy check, or CRC.
- And the CRC is nothing more than an algorithm that gives us a 32 bit value that's unique to this particular frame.
- Here's how that works.
- We take all those bits that were in the frame, and we shove them into this algorithm, which is really nothing
- more than a formula, and the formula spits out a 32 bit CRC value.
- Now that value is a unique 32 bit identifier for that precise frame.
- We take that CRC value, we put it into the FCS field of our frame, then what we do is we take our frame,
- we forward it from one device to the other device, the other device receives that frame, and then we do the
- cyclical redundancy check again. This time we take the exact bits of the frame that we received from the
- destination MAC address all the way to the end of the packet, we run it through the same CRC algorithm,
- spits out a 32 bit CRC value. This is the value of our received frame.
- We then will grab the FCS value that's contained in our frame trailer, and we compare the two.
- So we compare the CRC value of the frame that was sent to the CRC value of the frame that was received.
- And in this case, all the 1s and 0s match up, we're in good shape, it means the frame is legit and can be processed.
- At that point we'll take the packet out of the frame and figure out what to do with it.
- If, however, the received frame and the sent frame have different CRC values, let's say that by this orange
- arrow here in our received frame, instead of it being 01, it was actually 10.
- Well, now when we do our scan to find out if the frame has the same CRC value as sent and received,
- we'll encounter an error here indicating that there's something that changed in the frame along the way,
- which is entirely possible, the wire that the frame was being transmitted on may have encountered some very
- severe electrical magnetic interference, EMI, and it caused one of the bits to flip and now the frame has no integrity.
- And what happens then is the receiving device takes the device that has no integrity and it throws it in the
- trash, never to be seen again. Devices will never, ever ask using Ethernet at layer 2 to resend the junk frame.
- We have to rely on other services elsewhere in our OSI model or TCP/IP model protocols to help us recover
- those lost frames.