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