When we think about the concept of encapsulation, our focus tends to be more on
OSI models,
or OSI layers as part of the OSI model.
And so we're thinking about encapsulating, for example, a TCP datagram at layer
four
into an IP packet at layer three, which would turn into an Ethernet frame at
layer two.
This is sort of our standard way that we encapsulate our traffic and send it
through a TCP/IP network. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
through a TCP/IP network.
But what if we took this and rather than taking our TCP datagram and encaps
ulating it into
IP and then encapsulating it into Ethernet, what if we encapsulate it into
another IP header
before putting it into Ethernet?
What this accomplishes is it gives us two different headers.
It gives us an outer header and an inner header.
And this allows us to sort of hide one packet inside of the other. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And this allows us to sort of hide one packet inside of the other.
So this outer packet is going to be what's used for routing.
Our routers and layer three devices are going to take a look at this outer
header without
looking to or looking any further in, which makes sense because if a router
were to receive
this packet here, it would de-encapsulate Ethernet, look at the IP information, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
this packet here, it would de-encapsulate Ethernet, look at the IP information,
then re-encapsulate
Ethernet and send it on its way, assuming it's sending it out another Ethernet
interface.
But it never actually looks any deeper than the first IP header.
Now, same thing here.
It's going to de-encapsulate if it gets this packet.
It'll de-encapsulate our Ethernet.
It'll look at this IP header, then it will re-encapsulate Ethernet and send it
on, assuming
that it's not the destination and it's actually supposed to route this packet
and send it
out another interface. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
out another interface.
So it never looks inside.
It never sees the TCP or the inner IP header.
It is truly hidden inside of this.
So this concept is what we call tunneling.
Tunneling is when we hide one encapsulation or one header inside of something
else that's
intended to be carried through a different type of network.
And so what this creates is sort of this scenario here where maybe I've got a
series
of routers and these routers are all connected to each other. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
of routers and these routers are all connected to each other.
And I'm going to form, again, just thinking about it logically, form a tunnel
from one
router to the other.
The reason we draw it out this way is because when I send this packet down into
these devices,
which by the way, we're going to now refer to this as the underlay network, the
underlay
network only looks at the outer header.
Because it's only looking at the outer header, it never sees the inner header WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Because it's only looking at the outer header, it never sees the inner header
nor does it
need to know where the inner header is trying to get to.
So for example, let's say we're sending it from subnet A to subnet B. And
meanwhile,
we also have subnets C, D, and E throughout the process.
So where is the inner header destined for?
The inner header is trying to get to subnet B, but the outer header is trying
to get where?
Well, the outer header is just trying to get over to this router, which WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Well, the outer header is just trying to get over to this router, which
probably means
we're either trying to connect to a loopback interface or a virtual interface
like what
I have drawn here, or we could have done the tunnel over to this physical
interface here
that would be part of subnet E. But let's just say we're going to a loopback
interface.
Either way, we're trying to get, let's just call these routers one and four now
with router
two and router three in the middle.
So our outer is trying to actually get to this router for loopback address.
So this underlay, these two routers router two and router three, what do their WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So this underlay, these two routers router two and router three, what do their
routing
tables need to contain?
Well they need to have ownership of this underlay, meaning that they need to
have, they need
to have in their routing table installed entries for subnets C, D and E, but
they also are
going to need to have the loopbacks.
So let's just say that we've got our one loopback zero to our for loopback zero
.
So we're going to need our one loopback zero and our for loopback zero. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we're going to need our one loopback zero and our for loopback zero.
So notice that these underlay routers, they only need access or they only need
a routing
table that has entries for what do we got here, five subnets.
And also notice that out of this, we don't know where A is and we don't know
where B
is.
So is that a problem?
And the answer is no, it's not a problem because these are only looking at the
outer
header.
And the outer header is trying to get from entries, one entry that they know to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And the outer header is trying to get from entries, one entry that they know to
an entry
that they know as the destination, which is ultimately what we care about here,
is trying
to get to the destination.
So I can now receive this packet, look at the outer header, see, oh, you're
trying to
go to router for loopback zero subnet, whatever subnet that is, I happen to
have an entry
for that in my routing table.
It says for me to send that on to router three, router three says the same
thing.
It says to send it over to router four.
And now router four can bring that packet in and de encapsulate it and see that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And now router four can bring that packet in and de encapsulate it and see that
it was
destined for itself.
Now at this point, because router four is receiving, and we've got the ethernet
, we've
got the outer IP and the inner IP, again, it's going to de encapsulate this,
look at
this, see, oh, you're destined for me.
So now I'm going to de encapsulate the inner header or the outer header, this
is the outer
header.
And now I can look at the inner header, the inner IP header and see, oh, you're
destined
for a host out subnet B, because the inner has a destination that we know is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
for a host out subnet B, because the inner has a destination that we know is
going to
subnet B.
So did the underlay need to know where A or B was?
No, they didn't.
They had no clue where A and B were.
And yet the packet was still able to get delivered to subnet B.
This concept is going to be mission critical as we take a look coming up at
protocol such
as LISP and VXLAN.
And just tunneling in general is going to be very important for us to grasp.
We've got to talk about VPNs. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We've got to talk about VPNs.
We've got to talk about GRE.
We've got a lot to talk about with tunneling.
But sometimes we might look at a network diagram and say, oh, yeah, we just
have a tunnel
going between these two routers.
And so we just think it's all part of the same network and life is good.
But we really are creating two separate networks.
And if I use a different color here, we'll see that I've created an overlay
that looks
like this, where I'm actually writing this tunnel interface and connecting over
to where
subnet B exists. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
subnet B exists.
So this is my overlay in this situation.
And again, the underlay needs to know nothing about those overlay subnets in
the same way,
by the way, that overlays devices don't need to know about underlay subnets.
The only devices that need to know about both would be a device that supports
both.
And we see routers one and four are supporting both.
They've got underlay interfaces as well as overlay interfaces, including, by
the way,
the tunnel interface.
The tunnel interface is going to be part of that overlay network. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The tunnel interface is going to be part of that overlay network.
So with all of that in mind, we're now ready to talk about different tunneling
mechanisms.
And the first of which is going to be the generic routing encapsulation,
otherwise known
as GRE.
GRE is actually a Cisco protocol.
We can't run GRE on non-Cisco devices.
And interestingly, it was developed for something we don't use a whole lot WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And interestingly, it was developed for something we don't use a whole lot
anymore, which is
actually to carry non-IP traffic inside IP networks.
So the idea here is that we would take something like IPX traffic, which is
really old at this
point.
But it was certainly an option back when GRE was around.
And I say, hey, I've got these two disparate IPX networks.
How do I connect them together when the only thing I have in the middle here is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
How do I connect them together when the only thing I have in the middle here is
IP?
Well, I can actually tunnel IPX traffic through the IP domain.
And the way I would do this is make this the inner header concept and the outer
header
I would put IP and probably ethernet or potentially something else if it's
going across serial
links.
But either way, we see that we can construct this tunnel mechanism by-- and
also include
non-IP traffic. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
non-IP traffic.
Now there's a slight caveat to this.
And that is that we are not actually going to directly add the IP header.
We're going to insert a GRE header in here first.
This is sometimes known as a shim header.
We're kind of inserting it into the middle of a packet.
Then we'll have the IP and then ethernet.
And so GRE is going to include its own header.
And this just has some important information that's carried between the two WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And this just has some important information that's carried between the two
hosts.
Fortunately, it's not very large here.
It's only four bytes in size.
But we do have to consider the fact that we're also carrying additional
information-- or an
additional IP header in there as well.
So when we use it in the modern network, let's sort of shift gears here.
So in the modern network, we're going to be looking at not really communicating
with
non-IP and IP.
Instead we're still going to do what we drew over here, which is to include IP
inside
of IP. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
of IP.
So why do we use GRE?
Well, it's very simple to configure.
It's very easy to implement.
And why not use it?
To carry IP traffic inside of another IP header and create that underlay and
overlay concept.
And so now what we're looking at here is what we have drawn out already on the
right, which
is some kind of maybe UDP or TCP datagram.
And then we're going to have an inner IP header.
And then we'll have our GRE header. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then we'll have our GRE header.
And then we're going to have an outer IP header.
And then whatever layer two we have outside of that, probably ethernet.
But again, it's whatever layer two mechanism we're using.
So when we look at what we're adding here, we said we're adding four bytes for
the GRE
header.
But if we think about it, this is an entire payload in and of itself, whatever
we have
inside of the TCP/UDP datagram. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
inside of the TCP/UDP datagram.
So if I'm going to be building out ethernet frames at 1500 bytes, well,
normally I understand
that, OK, that's going to include some amount of information here.
So for example, it's going to include the payload.
It's going to factor in the ethernet and outer header.
But notice now we have an additional header.
And an IP header is 20 bytes.
This means that the MTU increase that we can expect is actually four bytes for WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
This means that the MTU increase that we can expect is actually four bytes for
GRE plus
20 additional bytes for the second IP header, which is a total of 24 bytes.
So any time we're looking at the concept of the underlay down here, this under
lay network
must support an increased MTU or we have to fragment these packets.
And I will tell you from experience that more often than not, we are fragment WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And I will tell you from experience that more often than not, we are fragment
ing packets
oftentimes without even realizing it.
So we need to be very careful about how exactly we construct our packets.
More often than not, it's better to increase the MTU on the underlay than it is
to try
to decrease the MTU on the end user devices and changing the tunnel.
The tunnel interface MTU is actually not going to help us out, even though that
's often cited
as a way for us to get around this. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
as a way for us to get around this.
Now one last tidbit of information before moving on is the fact that our IP
header is
going to have to have that protocol number in there to indicate what is encaps
ulated
inside of that.
And for GRE, we're going to include a protocol number of 47.
That can be important for allowing tunnels through firewalls, for example, or
access
control lists, whatever the situation is.
If our GRE isn't working, we might want to make sure that this IP protocol
number is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
number is
actually allowed.
So this is how tunneling comes together, how we can create an overlay in an
underlay,
and how GRE is one of the options that we have for including IP traffic and
encapsulating
it inside of another IP header.