It's a really good idea to do some verification of what
we think is happening on the network.
That betters our understanding.
So let's take a look at the implementation we just
did with GRE tunnels between R1 and R2.
And with packet captures, let's verify with the packets
about what exactly is going on.
So here is our topology and other tests.
Here's what I propose we do.
We'll go to PC1.
We'll generate some traffic that's going to hit 10.2.0.50
and what should happen is, PC1 should send it to its default
gateway, R1 should see it, and say, Oh the route WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
gateway, R1 should see it, and say, Oh the route
to 10.2 is to my GRE tunnel, tunnel 0, at which point
it should encapsulate that using GRE generic route
encapsulation, and ship it with an external header from itself,
its own IP address to the other end of the tunnel.
So we're going to capture the traffic here at point A,
here at point B, and then here at point C.
So here on the client PC, I'm going to go ahead and open up
a browser.
This is at site 1 and I'm going to go over
to 10.2.0.50 which is the PC or the device over at site 2. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to 10.2.0.50 which is the PC or the device over at site 2.
I'll hit refresh a few times and that
should generate some nice traffic for us between site 1
on 10.1.0, going over to 10.2.0.
All right, there is a lot of traffic here.
This is the capture at 10.1.0, that network segment,
and let's go ahead and find some HTTP traffic.
In fact, let me make that a little bit bigger.
How about this one right here.
We have a get request, HTTP get request,
coming from 10.1.0.50 to 10.2.0.50, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
coming from 10.1.0.50 to 10.2.0.50,
and let's expand that just a little bit.
We'll look at the internet protocol header
and I'm going to grab the identification field.
Right click on it and I'm going to say apply as filter,
as selected, and that should filter out
all the other packets except for this one.
And let me just copy that display filter.
Right-click copy and I will put it
on the capture I did in the cloud as well.
This is going to focus just on that one packet.
Fantastic, and I'm also going to apply it to our third capture
over at site 2 as well.
All right, so there's the same packet
on its journey through the network. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
on its journey through the network.
So here is at site 1, and I'll bring this up
so we can see a little bit better here.
And this here, we have an ethernet header,
we have an IP header with the source and destination,
and then we have the layer 4 header for TCP,
and then the actual HTTP payload.
If we look at the same packet as it crosses the internet
with GRE, check it out.
Here the layer 2 header information
would be R1's layer 2 address, the source,
going to whatever its default gateway is that goes up
to the cloud, and then at layer 3 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to the cloud, and then at layer 3
we have the source IP address of R1,
the destination address of R2 over the tunnel,
and then in this header, check it out,
it's pointing to protocol 47 as the next protocol.
So in the header of the layer 3 outside IP address information,
it's pointing to the next protocol, which is 47.
And so if we look at that header, that's GRE right there.
So there's the Generic Routing cancelation header
and this is also, in this header,
is pointing to what the payload is, what the customer
payload is it's carrying, which is hexadecimal 800,
which is IP version 4. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
which is IP version 4.
Then after that header, we have the original packet,
and this is what we matched on with the display filter.
So this is almost identical to the IP header
from the original customer before it got encapsulated,
except, the time to live is being decremented as it's
propagated through the network.
And then we continue on the source port
and destination port are all the same,
and the HTTP payload is just the same.
On the last leg of its journey, if we go to site 2,
here we have what looks like the original packet that
was sent from PC 1, but now this is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
was sent from PC 1, but now this is
the view of that packet over on the site 2 network of 10.2.0.
If we open up the IP header here,
we'll notice that the time to live
has decremented down to 62, and it will continue
to be as this packet is routed.
The key point here, if we go back to the cloud,
is that as it is being encapsulated,
it's being calculated in GRE, and then GRE
is specifying what the payload is that it's carrying.
And that's one of the benefits of generic route encapsulation,
is that we can carry other protocols
besides just IP version 4.
Also while we're here, we can also capture-- WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Also while we're here, we can also capture--
turn off the display filter--
we can also take a look at the EIGRP traffic that's
being advertised over this tunnel,
because it is also being encapsulated.
So there are some right there.
So this is the EIGRP.
It's showing coming from router 2 going
to router 1, based on the IP addresses of the tunnel,
and then in that IP header, specifying
that the next protocol is 47, which is GRE.
If you look at the GRE header, open it up,
it specifies it is carrying IP, and then we
have the original IP header.
So the original IP pack is sourced from 10.12.12.2, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So the original IP pack is sourced from 10.12.12.2,
which is R2, and it's going to the multicast address used
by EIGRP.
And in this header, it says the next protocol
is 88, which is EIGRP, and if we open up the EIGRP header,
it's showing us that this is a hello message, as indicated
right there.
So in this video, we've had the opportunity
to do some verification with a protocol analyzer, Wireshark,
to verify the encapsulation that GRE brings the table
and how it works.
Now, what's the problem with just using GRE?
The problem is, it's not protected.
It's not encrypted.
There's no data integrity checking.
So on top of the GRE tunnel, we can implement IP SEC, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So on top of the GRE tunnel, we can implement IP SEC,
and that's referred to as carrying
GRE traffic over IP SEC.
So in the next video, let's plan out
our strategy for the protocols we want to use for IKE phase
1 and IKE phase 2.
And then when we go to implement it,
I've got some good news for you.
There is an old way of implementing
this with crypto maps and a newer
way, which I'm going to show you in this set of videos.
So I'll see you in the very next video
as we plan out our IPsec strategy for protecting
this GRE traffic.
So until then, I hope this has been informative for you, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So until then, I hope this has been informative for you,
and I'd like to thank you for viewing.