Getting data moved from one part of the network
to the other relies on something called
a PDU, or a protocol data unit.
Sometimes you'll hear these referred to
as transmission units, because we're
taking a little bit of data and transferring it
across the network as a single unit.
For example, if we're running Ethernet,
we know that Ethernet is going to send everything
within an Ethernet frame from one device or MAC address
on the network to another MAC address that's on the network.
Ethernet, though, doesn't care what's
on the inside of this particular frame.
It's simply encapsulating all of the data that
may be underneath it and sending that across the network.
A similar thing happens at the next layer up with layer 3,
or the IP layer, where everything within the IP layer
is being sent across the network from one IP address
to the other.
Inside of that IP packet is UDP data, TCP data,
or some other type of data, but IP doesn't
care what's on the inside.
It simply knows that it's moving data
across the network from one IP address to another.
And where there is a TCP header or UDP header,
there's probably going to be a TCP segment, or what
we call a UDP datagram within that particular part
of the packet.
Here's an illustrated view of how
this operates at each layer of the OSI model,
and how data is encapsulated between each one
of those parts.
For example, let's start with using an application.
We're sending data within our application,
such as a web browser, and we need
to get that data sent from the web server to the web client.
That application data exists at OSI layers
5, 6, and 7, or what we will generically
call the application layers.
To be able to send that application data,
we need to transport it across the network using the TCP
protocol, so we'll put a TCP header right
in front of that application data
and send it across using that OSI layer 4,
or transport layer.
We have to have an IP address that
is able to send this TCP data and the application data that
might be inside of it, so we need
to add an IP header so that we can send information
from one IP address to another IP address.
And lastly, over Ethernet, we need
to have a DLC, or data link control, layer 2 frame header.
And in many cases, there's also a frame trailer
to indicate where the end of this frame might be.
The layer 2 frame header encapsulates
all of the information within.
So inside of this frame will be an IP header, a TCP header,
and ultimately, the application data
that we would like to send to the other side of the network.
Let's expand this view to show both the sending and receiving
device, and view the way the network might
interoperate with all of this.
So there's our application data at OSI layers 5, 6, and 7.
On the left side is the source address
that's sending this data, and we somehow
want to get that application data
to this destination device on the other side of the network.
We'll start by encapsulating this data by
including a TCP header, an IP header, and ultimately,
the frame header and frame trailer.
That information is going to be sent across the network, where
it will then be received by the destination device.
The destination device, though, needs the application data
that's inside--
it doesn't need all of this other information.
So it will begin decapsulating this information-- removing
the frame headers, removing the IP header,
and ultimately removing the TCP header
so that it can then access the application data.
And finally, we've been able to transfer this data
from the source device through the encapsulation
process, the decapsulation process,
and finally be able to receive the application
data at the destination.
Here's another way to visualize how
this data is being encapsulated and decapsulated on both sides.
We can start with our layer 5 through 7 application, data
such as HTTPS, IMAP email information, or SSH terminal
screens, where we're then going to take all of that
and encapsulate it within some type of layer for protocol.
This is commonly TCP or UDP.
We will then encapsulate the layer 4 traffic
within layer 3--
which, these days, is commonly IP traffic--
And then finally, layer 2 information on Ethernet.
That would be a media access control address or MAC address,
and that encapsulates all of this data within it.
In previous views of this data, we
mentioned that there's header information that
precedes the data associated with these layers.
And the header information is important
because it tells the rest of the data how
it should be processed.
For example, on layer 4, we have TCP data.
And within the TCP header, such as we have here,
there's information called a TCP flag.
This helps us understand how we can process this data as it's
going through the network.
This control information is setting
bits that are within the header of this packet,
and each one of those bits has a particular definition.
This means that the device that's receiving this data
can interpret those bits and understand how
to process the data properly.
We call these bits control flags,
and we can identify whether a flag has
been turned on or turned off, and then
decide how these particular flags can affect the data flow.
For example, we can look at the flags
in this particular protocol decode
and we can see that one flag has been set to 1.
That means the data that's contained within this TCP
part of the packet is acknowledgment data that
has been set.
You can see a number of different flags.
For example, if the SYN flag is set,
that means that there's a synchronization of sequence
numbers that's occurring.
If the push flag, or PSH flag, has been set,
it pushes the data to the application
without buffering anything else that might be incoming.
There's also a reset flag, or RST,
that resets the connection, and a FIN flag
that designates that this is the last packet that
will be sent by the sender.
By turning on or off different flags,
we can change how a device may interpret
the rest of the data that is being
sent using that TCP header.
Not only are there flags within the TCP or UDP header--
there are also flags within the IP header.
You can see an example of those flags right here.
Most of the flags being used at the IP header deal
with the fragmentation of data.
There may be times when you want to send traffic
across the network, but because of the architecture
or design of the network, you're,
not able to send packets that are very large.
In those cases, you may need to fragment
the data to be able to get through the smaller size
networks.
We determine the maximum size that you're
able to send using something called a maximum transmission
unit, or an MTU.
This designates the size of the data
that we're able to send through the network
without having to fragment any of that information further.
The reason we don't want to fragment
is that it commonly slows down the overall flow of traffic,
and if you can optimize your network communication
so that you're not fragmenting, you'll
have a much higher throughput of traffic.
This also eliminates any overhead
of having to chop the data into smaller pieces,
send those individual pieces across the network,
and then rebuild those pieces when
they get to the other side.
That's why it's important to know the MTU value that
would be used all the way through the network
from the beginning of the communication all
the way to the very end.
But understanding what the MTU might be
could sometimes be a very complicated process.
There may be many different hops that
are used to be able to communicate from point A
to point B, and each one of those hops
may be using a different MTU.
There is an automated process that your system will
use to attempt to determine what the MTU is when communicating
to that other device, but unfortunately,
if ICMP is filtered in that communication,
there's no way to automate that process, which
means you'll have to manually set the MTU on your side.
Let's take a look at what this fragmentation really means.
We've seen before, where we've taken some TCP, data
we put a TCP header in front of it, an IP header
in front of that, and finally, a DLC
header on the outside to send it across our Ethernet network.
The data that's on the inside from the IP header
all the way through to the data that's being transmitted
is our IP packet, and the maximum size
of an IP packet on an Ethernet network is 1,500 bytes.
If there's no fragmentation that's occurring anywhere
on the network, you'll be able to send all 1,500
bytes through the network without having any of that data
fragmented along the way.
Let's take an example, where we can only
send a very small amount of data through the network.
In this example, 16 bytes of data
is the maximum transmission unit that's
supported on this particular network.
That means we might have 44 bytes of data
that needs to be fragmented, and as we're sending it
through the network, we're going to fragment the first section
of it, or the first 16 bytes.
We'll then send another frame of data that has another 16 bytes,
and the last frame is going to send the remaining
amount of data, up to 16 bytes.
So if we do need to send data across the network that's
44 bytes in length, but the MTU of this network
is only 16 bytes, we're going to end up taking a single frame
and splitting it up into three separate frames.
Fortunately, when you're designing and creating
a network, the MTU is usually set during that creation
process, so once the network is built,
it's very unusual for that MTU to change.
We also know that there are going
to be MTU changes if we have to tunnel any information,
so if you're using a VPN of any type,
you're probably going to need to set some MTU
or ensure that the MTU is going to be properly set
automatically.
There is a flag within the IP part of the header that
will specify that the information you're sending
should not be fragmented as it goes through the network.
And if you send data that's too large with a Don't Fragment bit
set, that data may not be able to make it all
the way through the network.
And very commonly, you'll receive an ICMP message
saying that this data is too large
to send through this network.
If you'd like to test your network between one
device and another to see exactly what the MTU might be,
you can test by using the ping utility.
You can specify in ping to set that Don't Fragment bit,
and then you can force a particular size of data
to be sent through the network.
In the case of Ethernet, the maximum size
would be 1,472 bytes.
Now, normally, that would be 1,500 bytes,
but the ping command is specifying
that 1,500 bytes minus the ICMP header of 8 bytes,
and minus the 20-byte header of the IP
address itself, leaving us with 1,472 as the maximum MTU that
would be used for the ping command on an Ethernet network.
In Windows, you can test this by using the ping command
with the -f, which tells us to ping with the Don't Fragment
bit set, and then with -l, which specifies the length of data
you would like to use in bytes.
And in this case, it's 1,472 bytes.
And if you'd like to try this against Google's DNS server,
you can then use the IP address of 8.8.8.8.
Let's try this ping with the -f to don't fragment.
We'll do -l of 1,472 bytes, and let's
specify the DNS for Google.
And you can see that we are able to send traffic with 1,472-byte
ping frames from our device all the way through
to Google's DNS, and then we do receive a response back from
Google saying that that information was received.
If we tried to do a packet that was larger than 1,472--
let's try, for example, 1,482--
we'll send that information, and it
says this information needs to be fragmented,
but you've set the Don't Fragment bit, which
means it's not going to be able to traverse
this particular network, and you're going
to need to use a lower MTU.
If this was going over VPN, we would simply
keep moving that number lower and lower
until finally it was able to send through the network,
and we would be able to receive replies to our pings.