WEBVTT

1
00:00.000 --> 00:01.370 align:middle line:84%


2
00:01.370 --> 00:04.040 align:middle line:90%
It's a really good idea to
do some verification of what

3
00:04.040 --> 00:05.630 align:middle line:90%
we think is happening
on the network.

4
00:05.630 --> 00:07.020 align:middle line:84%
That betters our understanding.

5
00:07.020 --> 00:09.290 align:middle line:90%
So let's take a look at
the implementation we just

6
00:09.290 --> 00:11.960 align:middle line:90%
did with GRE tunnels
between R1 and R2.

7
00:11.960 --> 00:15.760 align:middle line:90%
And with packet captures,
let's verify with the packets

8
00:15.760 --> 00:17.700 align:middle line:84%
about what exactly is going on.

9
00:17.700 --> 00:19.403 align:middle line:90%
So here is our topology
and other tests.

10
00:19.403 --> 00:20.570 align:middle line:84%
Here's what I propose we do.

11
00:20.570 --> 00:22.370 align:middle line:84%
We'll go to PC1.

12
00:22.370 --> 00:26.480 align:middle line:90%
We'll generate some traffic
that's going to hit 10.2.0.50

13
00:26.480 --> 00:29.060 align:middle line:90%
and what should happen is, PC1
should send it to its default

14
00:29.060 --> 00:32.189 align:middle line:90%
gateway, R1 should see
it, and say, Oh the route
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

14
00:29.060 --> 00:32.189 align:middle line:90%
gateway, R1 should see
it, and say, Oh the route

15
00:32.189 --> 00:35.570 align:middle line:90%
to 10.2 is to my GRE tunnel,
tunnel 0, at which point

16
00:35.570 --> 00:38.930 align:middle line:90%
it should encapsulate that
using GRE generic route

17
00:38.930 --> 00:42.710 align:middle line:90%
encapsulation, and ship it with
an external header from itself,

18
00:42.710 --> 00:44.850 align:middle line:90%
its own IP address to the
other end of the tunnel.

19
00:44.850 --> 00:47.660 align:middle line:90%
So we're going to capture
the traffic here at point A,

20
00:47.660 --> 00:51.472 align:middle line:90%
here at point B, and
then here at point C.

21
00:51.472 --> 00:53.930 align:middle line:90%
So here on the client PC, I'm
going to go ahead and open up

22
00:53.930 --> 00:54.500 align:middle line:84%
a browser.

23
00:54.500 --> 00:57.140 align:middle line:90%
This is at site 1 and
I'm going to go over

24
00:57.140 --> 01:02.840 align:middle line:90%
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

24
00:57.140 --> 01:02.840 align:middle line:90%
to 10.2.0.50 which is the PC
or the device over at site 2.

25
01:02.840 --> 01:04.970 align:middle line:90%
I'll hit refresh a
few times and that

26
01:04.970 --> 01:08.030 align:middle line:90%
should generate some nice
traffic for us between site 1

27
01:08.030 --> 01:11.280 align:middle line:84%
on 10.1.0, going over to 10.2.0.

28
01:11.280 --> 01:13.030 align:middle line:90%
All right, there is a
lot of traffic here.

29
01:13.030 --> 01:17.010 align:middle line:90%
This is the capture at
10.1.0, that network segment,

30
01:17.010 --> 01:20.330 align:middle line:90%
and let's go ahead and
find some HTTP traffic.

31
01:20.330 --> 01:22.410 align:middle line:90%
In fact, let me make
that a little bit bigger.

32
01:22.410 --> 01:23.660 align:middle line:84%
How about this one right here.

33
01:23.660 --> 01:26.870 align:middle line:90%
We have a get request,
HTTP get request,

34
01:26.870 --> 01:30.380 align:middle line:90%
coming from 10.1.0.50
to 10.2.0.50,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

34
01:26.870 --> 01:30.380 align:middle line:90%
coming from 10.1.0.50
to 10.2.0.50,

35
01:30.380 --> 01:32.840 align:middle line:90%
and let's expand that
just a little bit.

36
01:32.840 --> 01:34.800 align:middle line:90%
We'll look at the
internet protocol header

37
01:34.800 --> 01:36.770 align:middle line:90%
and I'm going to grab
the identification field.

38
01:36.770 --> 01:40.190 align:middle line:90%
Right click on it and I'm
going to say apply as filter,

39
01:40.190 --> 01:42.110 align:middle line:90%
as selected, and that
should filter out

40
01:42.110 --> 01:44.030 align:middle line:90%
all the other packets
except for this one.

41
01:44.030 --> 01:46.370 align:middle line:90%
And let me just copy
that display filter.

42
01:46.370 --> 01:48.770 align:middle line:90%
Right-click copy
and I will put it

43
01:48.770 --> 01:50.810 align:middle line:90%
on the capture I did
in the cloud as well.

44
01:50.810 --> 01:53.570 align:middle line:90%
This is going to focus
just on that one packet.

45
01:53.570 --> 01:56.390 align:middle line:90%
Fantastic, and I'm also going
to apply it to our third capture

46
01:56.390 --> 01:58.010 align:middle line:84%
over at site 2 as well.

47
01:58.010 --> 01:59.720 align:middle line:90%
All right, so there's
the same packet

48
01:59.720 --> 02:01.920 align:middle line:90%
on its journey
through the network.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

48
01:59.720 --> 02:01.920 align:middle line:90%
on its journey
through the network.

49
02:01.920 --> 02:04.560 align:middle line:90%
So here is at site 1,
and I'll bring this up

50
02:04.560 --> 02:06.380 align:middle line:90%
so we can see a little
bit better here.

51
02:06.380 --> 02:08.690 align:middle line:90%
And this here, we have
an ethernet header,

52
02:08.690 --> 02:11.930 align:middle line:90%
we have an IP header with
the source and destination,

53
02:11.930 --> 02:14.690 align:middle line:90%
and then we have the
layer 4 header for TCP,

54
02:14.690 --> 02:17.360 align:middle line:90%
and then the actual
HTTP payload.

55
02:17.360 --> 02:19.910 align:middle line:90%
If we look at the same packet
as it crosses the internet

56
02:19.910 --> 02:21.392 align:middle line:84%
with GRE, check it out.

57
02:21.392 --> 02:22.850 align:middle line:90%
Here the layer 2
header information

58
02:22.850 --> 02:26.060 align:middle line:90%
would be R1's layer 2
address, the source,

59
02:26.060 --> 02:28.310 align:middle line:90%
going to whatever its default
gateway is that goes up

60
02:28.310 --> 02:30.620 align:middle line:90%
to the cloud, and
then at layer 3
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

60
02:28.310 --> 02:30.620 align:middle line:90%
to the cloud, and
then at layer 3

61
02:30.620 --> 02:33.060 align:middle line:90%
we have the source
IP address of R1,

62
02:33.060 --> 02:36.230 align:middle line:90%
the destination address
of R2 over the tunnel,

63
02:36.230 --> 02:38.330 align:middle line:90%
and then in this
header, check it out,

64
02:38.330 --> 02:41.640 align:middle line:90%
it's pointing to protocol
47 as the next protocol.

65
02:41.640 --> 02:44.930 align:middle line:90%
So in the header of the layer 3
outside IP address information,

66
02:44.930 --> 02:47.100 align:middle line:90%
it's pointing to the next
protocol, which is 47.

67
02:47.100 --> 02:50.460 align:middle line:90%
And so if we look at that
header, that's GRE right there.

68
02:50.460 --> 02:52.550 align:middle line:90%
So there's the Generic
Routing cancelation header

69
02:52.550 --> 02:53.950 align:middle line:90%
and this is also,
in this header,

70
02:53.950 --> 02:56.450 align:middle line:90%
is pointing to what the
payload is, what the customer

71
02:56.450 --> 02:59.210 align:middle line:90%
payload is it's carrying,
which is hexadecimal 800,

72
02:59.210 --> 03:01.130 align:middle line:84%
which is IP version 4.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

72
02:59.210 --> 03:01.130 align:middle line:84%
which is IP version 4.

73
03:01.130 --> 03:03.720 align:middle line:90%
Then after that header, we
have the original packet,

74
03:03.720 --> 03:06.180 align:middle line:90%
and this is what we matched
on with the display filter.

75
03:06.180 --> 03:09.290 align:middle line:90%
So this is almost
identical to the IP header

76
03:09.290 --> 03:11.570 align:middle line:90%
from the original customer
before it got encapsulated,

77
03:11.570 --> 03:15.170 align:middle line:90%
except, the time to live is
being decremented as it's

78
03:15.170 --> 03:16.650 align:middle line:84%
propagated through the network.

79
03:16.650 --> 03:18.080 align:middle line:90%
And then we continue
on the source port

80
03:18.080 --> 03:19.663 align:middle line:90%
and destination port
are all the same,

81
03:19.663 --> 03:21.980 align:middle line:90%
and the HTTP payload
is just the same.

82
03:21.980 --> 03:25.040 align:middle line:90%
On the last leg of its
journey, if we go to site 2,

83
03:25.040 --> 03:27.650 align:middle line:90%
here we have what looks like
the original packet that

84
03:27.650 --> 03:30.080 align:middle line:90%
was sent from PC
1, but now this is
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

84
03:27.650 --> 03:30.080 align:middle line:90%
was sent from PC
1, but now this is

85
03:30.080 --> 03:34.820 align:middle line:90%
the view of that packet over on
the site 2 network of 10.2.0.

86
03:34.820 --> 03:36.553 align:middle line:90%
If we open up the
IP header here,

87
03:36.553 --> 03:37.970 align:middle line:90%
we'll notice that
the time to live

88
03:37.970 --> 03:40.130 align:middle line:90%
has decremented down to
62, and it will continue

89
03:40.130 --> 03:42.230 align:middle line:84%
to be as this packet is routed.

90
03:42.230 --> 03:44.960 align:middle line:90%
The key point here, if
we go back to the cloud,

91
03:44.960 --> 03:46.910 align:middle line:90%
is that as it is
being encapsulated,

92
03:46.910 --> 03:49.700 align:middle line:90%
it's being calculated
in GRE, and then GRE

93
03:49.700 --> 03:51.967 align:middle line:90%
is specifying what the
payload is that it's carrying.

94
03:51.967 --> 03:54.550 align:middle line:90%
And that's one of the benefits
of generic route encapsulation,

95
03:54.550 --> 03:56.750 align:middle line:90%
is that we can carry
other protocols

96
03:56.750 --> 03:58.910 align:middle line:84%
besides just IP version 4.

97
03:58.910 --> 04:00.830 align:middle line:90%
Also while we're here,
we can also capture--
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

97
03:58.910 --> 04:00.830 align:middle line:90%
Also while we're here,
we can also capture--

98
04:00.830 --> 04:02.240 align:middle line:84%
turn off the display filter--

99
04:02.240 --> 04:05.960 align:middle line:90%
we can also take a look at
the EIGRP traffic that's

100
04:05.960 --> 04:07.460 align:middle line:90%
being advertised
over this tunnel,

101
04:07.460 --> 04:09.640 align:middle line:90%
because it is also
being encapsulated.

102
04:09.640 --> 04:11.280 align:middle line:84%
So there are some right there.

103
04:11.280 --> 04:12.250 align:middle line:84%
So this is the EIGRP.

104
04:12.250 --> 04:13.730 align:middle line:90%
It's showing coming
from router 2 going

105
04:13.730 --> 04:15.938 align:middle line:90%
to router 1, based on the
IP addresses of the tunnel,

106
04:15.938 --> 04:17.660 align:middle line:90%
and then in that IP
header, specifying

107
04:17.660 --> 04:20.810 align:middle line:90%
that the next protocol
is 47, which is GRE.

108
04:20.810 --> 04:23.120 align:middle line:90%
If you look at the GRE
header, open it up,

109
04:23.120 --> 04:25.220 align:middle line:90%
it specifies it is
carrying IP, and then we

110
04:25.220 --> 04:26.700 align:middle line:84%
have the original IP header.

111
04:26.700 --> 04:30.080 align:middle line:90%
So the original IP pack is
sourced from 10.12.12.2,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

111
04:26.700 --> 04:30.080 align:middle line:90%
So the original IP pack is
sourced from 10.12.12.2,

112
04:30.080 --> 04:33.050 align:middle line:90%
which is R2, and it's going
to the multicast address used

113
04:33.050 --> 04:34.205 align:middle line:84%
by EIGRP.

114
04:34.205 --> 04:36.080 align:middle line:90%
And in this header, it
says the next protocol

115
04:36.080 --> 04:39.920 align:middle line:90%
is 88, which is EIGRP, and if
we open up the EIGRP header,

116
04:39.920 --> 04:42.530 align:middle line:90%
it's showing us that this is
a hello message, as indicated

117
04:42.530 --> 04:43.030 align:middle line:84%
right there.

118
04:43.030 --> 04:44.822 align:middle line:90%
So in this video, we've
had the opportunity

119
04:44.822 --> 04:47.390 align:middle line:90%
to do some verification with a
protocol analyzer, Wireshark,

120
04:47.390 --> 04:50.540 align:middle line:90%
to verify the encapsulation
that GRE brings the table

121
04:50.540 --> 04:51.360 align:middle line:84%
and how it works.

122
04:51.360 --> 04:54.800 align:middle line:90%
Now, what's the problem
with just using GRE?

123
04:54.800 --> 04:56.750 align:middle line:90%
The problem is,
it's not protected.

124
04:56.750 --> 04:58.010 align:middle line:84%
It's not encrypted.

125
04:58.010 --> 04:59.690 align:middle line:90%
There's no data
integrity checking.

126
04:59.690 --> 05:04.223 align:middle line:90%
So on top of the GRE tunnel,
we can implement IP SEC,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

126
04:59.690 --> 05:04.223 align:middle line:90%
So on top of the GRE tunnel,
we can implement IP SEC,

127
05:04.223 --> 05:05.640 align:middle line:90%
and that's referred
to as carrying

128
05:05.640 --> 05:08.190 align:middle line:84%
GRE traffic over IP SEC.

129
05:08.190 --> 05:09.690 align:middle line:90%
So in the next
video, let's plan out

130
05:09.690 --> 05:12.555 align:middle line:90%
our strategy for the protocols
we want to use for IKE phase

131
05:12.555 --> 05:13.620 align:middle line:84%
1 and IKE phase 2.

132
05:13.620 --> 05:15.120 align:middle line:90%
And then when we
go to implement it,

133
05:15.120 --> 05:16.453 align:middle line:84%
I've got some good news for you.

134
05:16.453 --> 05:18.120 align:middle line:90%
There is an old
way of implementing

135
05:18.120 --> 05:19.890 align:middle line:90%
this with crypto
maps and a newer

136
05:19.890 --> 05:22.297 align:middle line:90%
way, which I'm going to show
you in this set of videos.

137
05:22.297 --> 05:23.880 align:middle line:90%
So I'll see you in
the very next video

138
05:23.880 --> 05:27.090 align:middle line:90%
as we plan out our IPsec
strategy for protecting

139
05:27.090 --> 05:28.470 align:middle line:84%
this GRE traffic.

140
05:28.470 --> 05:30.810 align:middle line:90%
So until then, I hope this
has been informative for you,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

140
05:28.470 --> 05:30.810 align:middle line:90%
So until then, I hope this
has been informative for you,

141
05:30.810 --> 05:33.950 align:middle line:90%
and I'd like to thank
you for viewing.