Welcome to Jeremy’s IT Lab. This is a free, complete course for the CCNA. If you like these videos, please subscribe
to follow along with the series. Also, please like and leave a comment, and
share the video to help spread this free series of videos. Thanks for your help. Also, remember to download and use the Anki
flashcards with the link in the description, which will help you very much in remembering
what you have learned. Let’s get started. In this video, we’re going to take a look
at the Internet Protocol version 4, known as IPv4 header. This is used at Layer 3, to help send data
between devices on separate networks, even on other sides of the world over the Internet. This is known as routing. Originally, I planned this video to be a general
introduction to routing, but in the end I decided to split it up into separate parts. Let’s take a look at what we’ll cover
in this video. We’ll cover the IPv4 packet structure, or
more accurately, the IPv4 header which is used to encapsulate a TCP or UDP segment. Specifically, we will cover the fields of
the IPv4 header. We already looked in detail at two fields
of the header, the source and destination IP address fields, but there are quite a few
more fields to look at. And that’s all for this video! As I said, I originally planned to make this
a long, introduction to routing video. However, I don’t want to make these videos
too long, already the shortest videos are at least 30 minutes which is quite long I
think. So, I decided to split up routing into more
videos. This prevents the videos from getting too
long, but also lets me go more in depth on each topic. So, this video will focus exclusively on the
fields in the IPv4 header, and then future videos will will get more practical, with
hands-on configuration in the CLI. Since we’re going to look at the IPv4 header,
let’s review its position in a complete frame. So, the upper layers of the OSI model prepare
some data to be sent to another device. It is encapsulated in a layer 4 header, typically
using the TCP or UDP protocols, which we’ll talk about in a future lesson. This combination of data plus layer 4 header
is called a segment. The segment is encapsulated with a Layer 3
header, usually using the internet protocol, IP. This combination of data, layer 4 header,
and layer 3 header, is called a packet. Then, the layer 2 header and trailer are added,
and this is called a frame. These units are called protocol data units,
or PDUs. For example, the layer 3 PDU is a packet,
and the layer 2 PDU is a frame. For this lesson, we’ll focus on this Layer
3 header, as it contains the information that is needed to route this packet to its destination. Note that, since we’ll be focusing on Layer
3 here, I’ll usually be using the term ‘packet’, talking about ‘routing packets’, rather than frames. So, thanks to Wikipedia for this chart of
the IPv4 header structure. As you can see, it’s a bit more complicated
than the Ethernet header. To be honest, I doubt that it will be necessary
for you to memorize the exact structure of the header, the
size of each field, etc, for the CCNA test, but I can’t make any guarantees, I didn’t
make the test. What I recommend is just getting to know the purpose
of each field of the header, which we’ll cover now. By the way, if you’re wondering how to read
this chart, it’s read left to right, top to bottom, so this is the first bit of the
header, and this is the last bit of the header. So, let’s quickly go through each field
of the header so you’re familiar with its purpose. First up is the ‘Version’ field of the
header. It’s length is 4 bits, half of one octet. It’s purpose is straight forward. It identifies the version of IP used. Now, there are only two versions of IP in
use, IPv4, which is simply identified with a value of 4 in this field, or 0 1 0 0 in
binary. The other version is Ipv6, which is identified
with a value of 6, or 0 1 1 0 in binary. Now you may wonder what happened to IPv5? Well there was an experimental protocol called
Internet Stream Protocol which uses an Internet Protocol value of 5, but it was never publically
used. So, you could say that’s the lost IPv5. Now, we’re focusing on the IPv4 header,
so this field of the header will always have a value of 4. The IPv6 header has a different structure
than the IPv4 header, so if the value of this field is 6 the rest of the header will have
a different structure. Next up is the Internet Header Length, or
IHL, field. It’s also 4 bits in length, half of one
octet. The final field of the IPv4 header (Options)
is variable in length, so this field is necessary to indicate the total length of the header. Here’s an important part to remember: This
field specifies the length of the header IN 4-BYTE INCREMENTS. For example, if the value in this field is
5, 5 times 4-bytes is 20, so that means that length of the header is 20 bytes. The minimum value in this field is 5, which
as I just said is equal to 20 bytes. That’s the length of the IP packet WITHOUT
any IP options at the end, so an empty options field. The maximum value is 15, which is the maximum
value of 4 bits, As you can see here, the values of the 4 bits are 1, 2, 4, and 8, adding
them up results in 15. So, 15 x 4 bytes is equal to 60 bytes. That means the maximum length of the IP options
field is 40 bytes. So, an IPv4 header with no options field is
20 bytes in length, and that’s the minimum length of an IPv4 header. And, an IPv4 with a maximum length options
field, 40 bytes, has a length of 60 bytes, and that’s the maximum length of an IPv4 header. Okay, that’s the IHL field of the IPv4 header. Next is the DSCP field. DSCP stand for differentiated services code
point, and the field’s length is 6 bits. This field is used for QoS, quality of service. Basic QoS is a topic on the CCNA so I will
make a dedicated video about it later. Essentially, it is used to prioritize delay-sensitive
data, such as streaming voice and video. If you’re loading a web page and the Internet
is a little slow, it’s not a big deal. However, if you’re having a skype call and
there’s terrible delay, or the audio and video keep freezing, it can totally ruin the
experience. This field is used to identify which traffic
should receive priority treatment. Next up is the ECN field, which stands for
explicit congestion notification and has a length of 2 bits. It provides end-to-end notification of network
congestion WITHOUT DROPPING PACKETS. Normally in a network, if the network is super
busy, if there is congestion, this is signalled by dropping packets. The ECN field provides a way to signal a congested
network without dropping packets. However, this is an optional field that requires
both endpoints, as well as the underlying network infrastructure, to support it. Next up is the Total Length field, and its
length is 16 bits, or 2 octets, 2 bytes. It indicates the total length of the packet,
including the IPv4 header and the encapsulated Layer 4 segment, which includes both the layer
4 header and the data. This is different than the IHL field, which
indicates only the length of the IPv4 header itself. This field indicates the length in bytes,
NOT IN 4-BYTE INCREMENTS LIKE THE IHL HEADER. So, a value of 20 in this field simply means
20 bytes. The minimum value in this field is 20, meaning
20 bytes, which is equal a minimum-sized IPv4 header with no encapsulated data. The maximum value is 65,535, which is the
maximum value of 16 binary bits, all set to 1. Let me just show you that calculation. Here are 16 bits, two octets, all set to 1. The first bit is equal to 1, then 2, then
4...8...16...32...64...128. This is as far as we went when looking at
a single octet in an IPv4 address. If you extend beyond 8 bits, the value keeps
doubling. Next is 256...512...1024...2048...4096...8192...16,384...and then
the 16th bit is 32,768. Add those all up, and you get 65535, the maximum
length of an IPv4 packet. Next up is the Identification field, which
is also 16 bits in length. If a packet is fragmented due to being too
large, this field is used to identify which packet the fragment belongs to, so it can
be reassembled again to make the original packet. All fragments of the same packet will have their
own IPv4 header with the same value in this field., so they can be reassembled later. Packets are fragmented if larger than the
MTU, which stands for Maximum Transmission Unit. The MTU is usually 1500 bytes. Remember the maximum size of an Ethernet frame? I mentioned that the maximum payload size
of an Ethernet frame is 1500 bytes, so these are related. And one last point, fragments are reassembled by
the receiving host. Next is the Flags field, which is 3 bits in
length. It is used to control and identify fragments. There are 3 bits, and they function like this. The first bit, bit 0, is reserved and always
set to 0. Bit 1 is the don’t fragment bit, or DF bit. If it is set to 1, it means that the packet
should not be fragmented. Bit 2 is the more fragments, or MF bit. It is set to 1 if there are more fragments
in the packet, and then set to 0 for the last fragment. Also, if the packet is a whole, unfragmented
packet, the MF bit is set to 0, since there are no fragments. Next we have one more field related to packet
fragmentation, that is the fragment offset field, which is 13 bits in length. This field is used to indicate the position
of the fragment within the original, unfragmented IP packet. This allows fragmented packets to be reassembled
even if the fragments arrive out of order, since this field lets the receiver know the
original order of the fragments. Next up is the Time to Live Field, which is
8 bits in length. A router will drop a packet with a TTL of
0. So, this field is used to prevent infinite
loops. If a poor routing configuration causes a packet
to be continually sent around in a loop, never reaching its intended destination, if enough
traffic like that accumulates, it could causes network congestion, and eventually failure. This feature prevents that by happening, causing
looped traffic to be dropped when the TTL reaches 0. This field was originally designed to indicate
the packet’s maximum lifetime in seconds, in practice, however, this actually indicates
a ‘hop count’. Each time the packet arrives at a router on
the way to its destination, the router decreases the TTL by 1, until the packet reaches its
destination, or the TTL reaches 0 and the packet is dropped. The current recommended default TTL is 64. Next up is the Protocol field, which is also
8 bits in length. It indicates the protocol of the encapsulated
Layer 4 PDU. Typically, this will be one of the following:
TCP, which is indicated by a value of 6, or UDP, which is indicated by a value of 17. I haven’t talked about TCP and UDP yet,
but that I will make a dedicated video about them later. For now, try to remember their protocol numbers
of 6 for TCP and 17 for UDP. You might also see a value of 1, which is
used for ICMP, the protocol ping uses. Another one to remember is 89, which is OSPF,
which stands for Open Shortest Path First. OSPF is a dynamic routing protocol which allows
routers to learn routes to destinations from their neighbors, without us having to manually
configure the routes. We will cover OSPF in depth in this course,
so for now just try to remember the protocol number of 89. If you’re curious, you can check a list
of protocol numbers at this page on wikipedia. Don’t worry about memorizing any others,
but try to remember these four. The included flashcards are extremely useful
for remembering little facts like these. Next is the header checksum field, which is
16 bits in length. It is a calculated checksum used to check
for errors in the Ipv4 header. When a router receives a packet, it calculates
the checksum of the header and compares it to the one in this field of the header. If the newly calculated checksum and the checksum
in the IPv4 header do not match, it means that an error has occurred in transmission,
so the router drops the packet. Note that this is only used to check for errors
in the IPv4 header, not in the encapsulated data. IP relies on the encapsulated protocol to
do that. Both UDP and TCP, the two Layer 4 protocols
most likely to be encapsulated, have checksum fields to check for errors in the encapsulated
data. Okay, next up are the Source and Destination
IP Address fields, which I covered in detail already. As you already know, they are 32 bits in length
each, as that is the length of an IPv4 address. The source IP address field indicates the
IPv4 address of the sender of the packet. The destination IP address field indicates
the IPv4 address of the intended receiver of the packet. Finally, the options field, which is optional
and can be 0 bits in length if not used, or up to 320 bits, 40 bytes, in length. This field is rarely used, however if the
IHL, Internet header length, field is greater than 5, is means that options are present. Here is a chart from Wikipedia showing the
structure of the Options field, you can check it out or read more online if you’re interested,
but for the purposes of CCNA studies I don’t think you need to worry about it. Okay, now we’ve covered all of the fields
of the IPv4 header. It’s a bit more complicated than the simple
Ethernet header and trailer we already learned about, but hopefully you understand the purpose
of each field now. For the purpose of the CCNA, I think the information
presented in this video is sufficient, but of course feel free to read more, a simple
Google search will give you many good resources. Also don’t forget to use the Anki flashcards
to help you remember everything. Now let’s go in depth and analyze a packet
capture from Wireshark. I showed you Wireshark before, and its an
extremely useful tool both for learning, and also in the real world to troubleshoot problems. This isn’t a wireshark course, but I will
show you wireshark at various points in this course, and if you have a lab with real Cisco
equipment, or a virtual lab using GNS3, I highly recommend you use Wireshark to examine
network traffic like this, it will really help you in your studies. But in either case, I will show you Wireshark
packet captures in this course, so don’t worry if you aren’t able to use it yourself. So, I sent a ping between two routers, notice
under the INFO column it says echo (ping) request. I have selected the frame here, meaning the
entire frame and you can see down here that the entire frame is highlighted. These digits are a hexadecimal representation
of the frame. Now I highlighted the Ethernet header, and
down at the bottom you can see only the Ethernet header section of the frame is highlighted. Then I highlight the IP header, and at the
bottom only the IP header section of the frame is highlighted. Then I highlight the packet’s payload, which
is Internet Control Message Protocol, or ICMP, the protocol used by ping, and you can see
the payload highlighted at the bottom. In this video we’re focusing on the IPv4
header, so let’s expand the Internet Protocol Version 4 information. Okay, so I’ve expanded the IPv4 header section
and zoomed up a bit, and here you can see all of the fields we looked at in this video,
except Options. As I said, options are rarely used, and they
aren’t in this packet. First up, the Version field, and V you can see the
binary bits 0100 on the left, and it shows you that means version 4. Next is the header length which is the IHL
field. It has a binary value of 0101, which equals
5. Remember, this field indicates the length
in units of 4 bytes, so this value of 5 means a header length of 20 bytes. That is the minimum header length, and it
is the length of an IPv4 header with no options field. Next up is the differentiated services field,
and as you can see Wireshark categorizes both the DSCP, differentiated services codepoint,
and ECN, explicit congestion notification, fields under this section. Both are set to 0, as they are not being used. Next up is the total length. This represent the total length of the IP
packet in bytes, including both the header and the ICMP data it encapsulates. So, this 100 means that the total length is
100 bytes. Next is the identification field. This packet has an identification field of
5. It’s not fragmented, but if it were fragmented,
the other fragments belonging to this packet would also have a value of 5 here. Next up is the flags field. Notice that Wireshark also includes the fragment
offset field under this section. The reserved bit is always 0. That’s what ‘not set’ means by the way. I sometimes say ‘set to 0’ or ‘set to
1’, but another way of saying it is ‘not set’, which means 0, or ‘set’, which
means 1. The don’t fragment bit isn’t set, so this
packet can be fragmented, if necessary. The more fragments bit also isn’t set, which
is expected as the packet isn’t fragmented. The fragment offset field is also 0, which
is also expected in a packet that isn’t fragmented. Next is the Time to Live field, which is set
to 255, the maximum. Remember, the time to live field is 8 bits
in length, and 255 is the maximum 8-bit value. The protocol is ICMP, because I used ping. Notice the protocol value of 1 which indicates
this. You can see the header checksum here. Remember it’s a 16-bit value. 0X indicates hexadecimal, and then each hexadecimal
digit is equal to 4 bits, so 4 times 4 is 16, 16 bits. Here’s the source IP address, and finally
the destination IP address. The standard PING command on a Cisco router
will send 100-byte pings, which is why the ping I showed you wasn’t fragmented. But, I pinged once more, using this command
ping 192.168.1.2 SIZE 10000, which will send 10,000 byte pings, much larger than the 1500
bytes MTU. So, this will cause fragmentation. As you can see here, there are a bunch of
IP fragments. They all say ‘reassembled in #13’. What is #13? Well, it’s this ICMP echo request right here. Now, let’s take a look at some of the IPv4
header fields in these fragments. Okay, so these are the details of just the
first two fragments. First off, notice the total length of 1500
bytes, so this 10,000 byte ping was divided up into 1500 byte fragments, which is equal
to the MTU size. Then, notice the identification field of 1. This is different than the last packet I showed
you, but notice that the value is the same for these two fragments. Then take a look at the flags. Each of them has the more fragments bit set,
because neither of these is the last fragment in the packet. Also, notice that each of them has a different fragment
offset value, however, and that the first fragment has an offset of 0. Just one more thing, this time I sent a ping
and set the don’t fragment bit by adding the ‘df-bit’ option to the ping command. As you can see here, now the don’t fragment
bit is set. Because I didn’t set the size, the default
ping size of 100 bytes was used, so it was no problem that these packets weren’t allowed
to be fragmented. However, if I send pings that are larger than
the MTU, AND set the DF-bit, you can see the pings fail. They were too large to be sent unfragmented,
but also not allowed to be fragmented. Before moving on to today’s quiz let’s
review what we studied. We looked at the structure of an IPv4 packet,
more specifically the fields of the IPv4 header. That’s it. It doesn’t look like a lot when you list
it like this, but I’m sure you agree that was a lot of information. In the next video we’ll get more practical
and hands-on, getting into the CLI to see how to configure routes. Okay let’s move on to today’s quiz. In addition to the quiz, make sure to download
and use the Anki flashcards to help you remember all of the details you learned in this video. Let’s get started with question 1. What is the fixed binary value of the first
field of an IPv4 header? A, 0010. B, 0110. C, 0001. D, 0100. Pause the video to think about your answer. The answer is D, 0100. The first field of the IPv4 header is the
version field. Because the question is about an IPv4, or
Internet Protocol VERSION 4 header, the version field is always set to 4, or 0100 in binary. let’s go to question 2. Which field will cause the packet to be dropped
if it has a value of 0? A, TTL. B, DSCP. C, IHL. D, ECN. Pause the video to think about your answer. The answer is A, TTL. TTL stands for Time To Live. It is reduced by 1 at each router the packet
passes through. If it reaches 0, the packet is dropped. Let's go to question 3. How are errors in an IPv4 packet’s encapsulated
data detected? A, the IPv4 header checksum field checks for
errors. B, the encapsulated protocol, for example
TCP or UDP, checks for errors. C, Errors in the encapsulated data cannot
be detected. Pause the video to think about your answer. The answer is B, the encapsulated protocol
checks for errors. The IPv4 Header Checksum field only checks
for errors in the IPv4 header itself. However, Layer 4 protocols like TCP or UDP
can use their checksum to check for errors in the encapsulated data. Let’s go to question 4. Which field of an Ipv4 header is variable
in length? A, options. B, header checksum. C, total length. D, IHL. Pause the video to think about your answer. The answer is A, Options. The Options field can vary in length from
0 bits to 320 bits. The other fields are fixed-length. Although the Total Length and IHL fields are
used to represent the variable length of the IPv4 header and packet, the fields themselves
are fixed in length. Let’s go to question 5. Which bit will be set to 1 on all IPv4 packet
fragments except the last fragment? A, fragment offset bit. B, more fragments bit. C, dont fragment bit. D, packet fragment bit. Pause the video to think about your answer. The answer is B, more fragments bits. The More Fragments bit, part of the Flags
field of the IPv4 header, is used to indicate that the current fragment is not the last
fragment of a fragmented packet. It is set to 1 on all fragments except the
last, which will set it to 0. A, fragment offset, is a 13-bit field in the
header, not a single bit. C, Don’t fragment bit, is used to prevent
a packet from being fragmented. And D, packet fragment bit, is not a real
bit in the IPv4 header. Okay, that’s all for the quiz. Remember to use the supplementary materials
to help you remember what you’ve studied. There will be Anki flashcards to help you
review what you’ve studied. For a video like this, I think the flashcards
are particularly important, so remember to download and use them. There will be a packet tracer lab for routing,
but not after this video. Wait until after day 11’s video to get some
hands-on practice configuring routing on a Cisco router. Good luck with your studies. Thank you for watching. Please subscribe to the channel, like the
video, leave a comment, and share the video with anyone else studying for the CCNA. If you want to leave a tip, check the links
in the description. I'm also a Brave verified publisher and accept
BAT, or Basic Attention Token, tips via the Brave browser. That's all for now.