WEBVTT

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


2
00:00.828 --> 00:02.370 align:middle line:90%
Have you ever had
one of those things

3
00:02.370 --> 00:04.120 align:middle line:90%
where you thought was
fantastic and great?

4
00:04.120 --> 00:06.150 align:middle line:90%
And as you get into it,
you realize that, Oh,

5
00:06.150 --> 00:08.910 align:middle line:90%
it doesn't quite as good as I
thought, or doesn't do this,

6
00:08.910 --> 00:10.100 align:middle line:84%
or doesn't do that.

7
00:10.100 --> 00:14.040 align:middle line:90%
Well, that's the case with
crypto map based IPSec VPNs

8
00:14.040 --> 00:17.250 align:middle line:90%
because there are some features
that are just not supported

9
00:17.250 --> 00:19.860 align:middle line:90%
if we're using crypto maps and
IPSec tunnels by themselves.

10
00:19.860 --> 00:21.325 align:middle line:90%
So in this video,
I'd like to share

11
00:21.325 --> 00:22.950 align:middle line:90%
with you what some
of those limitations

12
00:22.950 --> 00:24.210 align:middle line:84%
are, but have no fear.

13
00:24.210 --> 00:26.520 align:middle line:90%
I'd like to show you a
solution as well that involves

14
00:26.520 --> 00:28.952 align:middle line:84%
generic route encapsulation.

15
00:28.952 --> 00:30.660 align:middle line:90%
So let's use this
topology as an example.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

15
00:28.952 --> 00:30.660 align:middle line:90%
So let's use this
topology as an example.

16
00:30.660 --> 00:33.300 align:middle line:90%
We'll call this site 1, and
over here we'll have site 2.

17
00:33.300 --> 00:34.440 align:middle line:84%
You got it.

18
00:34.440 --> 00:36.420 align:middle line:90%
And if we're using
the traditional IPSec,

19
00:36.420 --> 00:39.720 align:middle line:90%
we'd have our tunnel
between R1 and R2.

20
00:39.720 --> 00:41.940 align:middle line:90%
And then there's
traffic from PC1 one

21
00:41.940 --> 00:43.800 align:middle line:84%
is sent to the default gateway.

22
00:43.800 --> 00:46.890 align:middle line:90%
R1 would say, Oh, but is this
coming from 10.1 going to 10.2?

23
00:46.890 --> 00:48.620 align:middle line:90%
If so, I need to go
ahead and encrypt it.

24
00:48.620 --> 00:51.330 align:middle line:90%
It encrypts it, shoots it
over the tunnel over to R2.

25
00:51.330 --> 00:53.132 align:middle line:90%
R2 decrypts it and
forwards on its way.

26
00:53.132 --> 00:54.840 align:middle line:90%
So let's talk about
some of the problems,

27
00:54.840 --> 00:56.257 align:middle line:90%
and ask the question
what are some

28
00:56.257 --> 00:58.410 align:middle line:90%
of the problems about
IPSec in this fashion?

29
00:58.410 --> 01:02.190 align:middle line:90%
One problem is that this leg
of the journey right here,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

29
00:58.410 --> 01:02.190 align:middle line:90%
One problem is that this leg
of the journey right here,

30
01:02.190 --> 01:05.830 align:middle line:90%
it doesn't have a logical IP
address, a network address.

31
01:05.830 --> 01:08.927 align:middle line:90%
So if we want to do manipulation
based on that logical tunnel,

32
01:08.927 --> 01:10.510 align:middle line:90%
it doesn't have an
IP network address.

33
01:10.510 --> 01:11.885 align:middle line:90%
There's no option
for doing that.

34
01:11.885 --> 01:15.690 align:middle line:90%
We can't call this the 10.2
network, or the 172.16 network,

35
01:15.690 --> 01:16.410 align:middle line:84%
or anything else.

36
01:16.410 --> 01:19.240 align:middle line:90%
Because with traditional
IPSec all by itself,

37
01:19.240 --> 01:21.720 align:middle line:90%
this connectivity, this
tunnel, this logical security

38
01:21.720 --> 01:23.460 align:middle line:90%
association between
R1 and R2, it

39
01:23.460 --> 01:26.070 align:middle line:90%
doesn't have an IP
network address base.

40
01:26.070 --> 01:28.800 align:middle line:90%
Now another challenge
with this logical tunnel

41
01:28.800 --> 01:31.260 align:middle line:90%
is that it doesn't
support broadcasts,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

41
01:28.800 --> 01:31.260 align:middle line:90%
is that it doesn't
support broadcasts,

42
01:31.260 --> 01:33.478 align:middle line:90%
and it also doesn't
support multicast.

43
01:33.478 --> 01:35.520 align:middle line:90%
And we might say to
ourselves, Well, no big deal.

44
01:35.520 --> 01:37.890 align:middle line:90%
I really don't need a bunch
of broadcast or multicast

45
01:37.890 --> 01:39.240 align:middle line:84%
going between these peers.

46
01:39.240 --> 01:41.340 align:middle line:90%
But there are some
protocols that we might

47
01:41.340 --> 01:43.290 align:middle line:84%
want to use that need those.

48
01:43.290 --> 01:46.060 align:middle line:90%
Somewhat include things
like routing protocols.

49
01:46.060 --> 01:48.750 align:middle line:90%
So if we want to have R1
and R2 dynamically exchange

50
01:48.750 --> 01:51.780 align:middle line:90%
routing information
with OSPF or EIGRP

51
01:51.780 --> 01:53.820 align:middle line:90%
because those routing
protocols collectively

52
01:53.820 --> 01:56.280 align:middle line:90%
require the use of broadcast
and multicast traffic

53
01:56.280 --> 01:57.113 align:middle line:84%
in their operations.

54
01:57.113 --> 01:59.697 align:middle line:90%
Because this doesn't support it,
and it doesn't have a network

55
01:59.697 --> 02:00.510 align:middle line:84%
address base.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

55
01:59.697 --> 02:00.510 align:middle line:84%
address base.

56
02:00.510 --> 02:04.290 align:middle line:90%
That means we cannot use routing
protocols over an IPSec tunnel.

57
02:04.290 --> 02:06.810 align:middle line:90%
Also IPSec, if we look
at the name of it,

58
02:06.810 --> 02:09.330 align:middle line:90%
IPSec is a suite of
protocols that we

59
02:09.330 --> 02:10.539 align:middle line:84%
can use to protect traffic.

60
02:10.539 --> 02:11.610 align:middle line:84%
But what kind of traffic?

61
02:11.610 --> 02:13.360 align:middle line:84%
The answer is IP traffic.

62
02:13.360 --> 02:16.590 align:middle line:90%
So if we need to protect other
type of protocols other than IP

63
02:16.590 --> 02:21.090 align:middle line:90%
going between R1 and R2, IPSec
by itself cannot get the job

64
02:21.090 --> 02:21.670 align:middle line:84%
done.

65
02:21.670 --> 02:23.170 align:middle line:90%
So what do we do
with this quandary?

66
02:23.170 --> 02:25.650 align:middle line:90%
Do we raise our hands
up and then say, Oh, no?

67
02:25.650 --> 02:28.410 align:middle line:90%
No, we can use other solutions
in combination with IPSec.

68
02:28.410 --> 02:31.290 align:middle line:90%
And one solution that really
brings a lot to the table
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

68
02:28.410 --> 02:31.290 align:middle line:90%
And one solution that really
brings a lot to the table

69
02:31.290 --> 02:35.160 align:middle line:90%
is a three-letter
acronym of GRE.

70
02:35.160 --> 02:39.250 align:middle line:90%
And the acronym stands for
Generic Route Encapsulation.

71
02:39.250 --> 02:42.450 align:middle line:90%
And the benefit is we could make
a GRE tunnel between these two

72
02:42.450 --> 02:44.970 align:middle line:90%
pairs first, and
that GRE tunnel could

73
02:44.970 --> 02:47.580 align:middle line:90%
do lots of things, including
having a network address base

74
02:47.580 --> 02:49.240 align:middle line:84%
associated with that tunnel.

75
02:49.240 --> 02:52.470 align:middle line:90%
We can also carry other
protocols besides just IP.

76
02:52.470 --> 02:55.230 align:middle line:90%
And because we have
the ability to have

77
02:55.230 --> 02:58.030 align:middle line:90%
that logical IP addressing,
that network between them,

78
02:58.030 --> 03:00.570 align:middle line:90%
and we can now support
broadcast and multicast,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

78
02:58.030 --> 03:00.570 align:middle line:90%
and we can now support
broadcast and multicast,

79
03:00.570 --> 03:03.540 align:middle line:90%
we could run a routing
protocol between R1 and R2,

80
03:03.540 --> 03:06.450 align:middle line:90%
and they could train each other
about their interior networks

81
03:06.450 --> 03:08.050 align:middle line:84%
for reachability purposes.

82
03:08.050 --> 03:10.140 align:middle line:90%
So with GRE, think
of it like a carrier

83
03:10.140 --> 03:13.260 align:middle line:90%
that can carry other
protocols as its customers

84
03:13.260 --> 03:15.330 align:middle line:90%
or its payload, as
it sends packets

85
03:15.330 --> 03:18.660 align:middle line:90%
back and forth between the
two ends of that tunnel.

86
03:18.660 --> 03:21.650 align:middle line:90%
And let's take a peek of what
that might look like with GRE.

87
03:21.650 --> 03:23.790 align:middle line:90%
With GRE, we'd still
create a tunnel,

88
03:23.790 --> 03:25.740 align:middle line:90%
and it would start here
at R1 and end at R2.

89
03:25.740 --> 03:29.490 align:middle line:90%
Or if you're at site 2, you say
it starts at R2 and ends at R1.

90
03:29.490 --> 03:31.600 align:middle line:90%
It's a tunnel it
goes both directions.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

90
03:29.490 --> 03:31.600 align:middle line:90%
It's a tunnel it
goes both directions.

91
03:31.600 --> 03:36.110 align:middle line:90%
So now when PC1 sends
a packet to 10.2.0.50,

92
03:36.110 --> 03:37.920 align:middle line:90%
he forwards it to
the default gateway.

93
03:37.920 --> 03:39.690 align:middle line:90%
R1 sees it, and
based on the routing,

94
03:39.690 --> 03:42.480 align:middle line:90%
it says, Oh, I need to send
this the next hop as the IP

95
03:42.480 --> 03:43.870 align:middle line:84%
address of R2 over this tunnel.

96
03:43.870 --> 03:50.870 align:middle line:90%
So maybe this tunnel has a
logical address of 10.12.12.0,

97
03:50.870 --> 03:54.100 align:middle line:90%
and R1 has dot 1,
and R2 has that 2.

98
03:54.100 --> 03:56.100 align:middle line:90%
And so from a
routing perspective,

99
03:56.100 --> 03:58.690 align:middle line:90%
if R1 saw that, Oh, to
get to the 10.2 network,

100
03:58.690 --> 04:01.652 align:middle line:90%
the next hop is
10.12.12.2, it then say,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

100
03:58.690 --> 04:01.652 align:middle line:90%
the next hop is
10.12.12.2, it then say,

101
04:01.652 --> 04:03.360 align:middle line:90%
I need to route up
this tunnel interface.

102
04:03.360 --> 04:05.277 align:middle line:90%
And let's take a look
at what that looks like.

103
04:05.277 --> 04:06.960 align:middle line:90%
So the original
packet from PC1, I'm

104
04:06.960 --> 04:08.910 align:middle line:90%
going to put in
the IP header here.

105
04:08.910 --> 04:12.350 align:middle line:84%
And then I'll put PC1 to PC2.

106
04:12.350 --> 04:13.890 align:middle line:84%
That's the original IP header.

107
04:13.890 --> 04:16.980 align:middle line:90%
And then we have the
payload behind that.

108
04:16.980 --> 04:20.042 align:middle line:90%
[INAUDIBLE] that payload was
an ICP echo request or maybe is

109
04:20.042 --> 04:21.959 align:middle line:90%
looking for a web services,
or whatever it is,

110
04:21.959 --> 04:24.510 align:middle line:90%
but there's the IP header
and then the payload.

111
04:24.510 --> 04:26.430 align:middle line:90%
And so what happens
when R1 sees it?

112
04:26.430 --> 04:28.970 align:middle line:90%
R1 says, Oh, I'm going to
route this with the GRE tunnel.

113
04:28.970 --> 04:31.410 align:middle line:90%
I'm going to go ahead and
I'm going to add a header.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

113
04:28.970 --> 04:31.410 align:middle line:90%
I'm going to go ahead and
I'm going to add a header.

114
04:31.410 --> 04:32.530 align:middle line:84%
And here's the header.

115
04:32.530 --> 04:33.945 align:middle line:84%
It's going to add a GRE header.

116
04:33.945 --> 04:35.820 align:middle line:90%
And then in front of
that, the outside header

117
04:35.820 --> 04:38.070 align:middle line:90%
is then going to have the
IP addresses for source

118
04:38.070 --> 04:40.290 align:middle line:84%
would be R1's interface.

119
04:40.290 --> 04:42.600 align:middle line:90%
And the destination would
be R2's interface that's

120
04:42.600 --> 04:43.880 align:middle line:84%
reachable over this network.

121
04:43.880 --> 04:46.840 align:middle line:84%
So I'm going to put R1, R2 here.

122
04:46.840 --> 04:48.630 align:middle line:90%
So in this outside
header, it points

123
04:48.630 --> 04:50.263 align:middle line:84%
to the next protocol of GRE.

124
04:50.263 --> 04:51.930 align:middle line:90%
And then in the GRE
header, it indicates

125
04:51.930 --> 04:54.075 align:middle line:90%
that the protocol being
carried here is IP.

126
04:54.075 --> 04:57.570 align:middle line:90%
The internet would see a packet,
a GRE packet, that source

127
04:57.570 --> 04:58.710 align:middle line:84%
from R1 going to R2.

128
04:58.710 --> 05:00.960 align:middle line:90%
And then if you didn't
encapsulate that and look at it
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

128
04:58.710 --> 05:00.960 align:middle line:90%
And then if you didn't
encapsulate that and look at it

129
05:00.960 --> 05:03.020 align:middle line:90%
further, we get to
the original payload.

130
05:03.020 --> 05:06.250 align:middle line:90%
So when the R2 see us, it
would de-encapsulate that.

131
05:06.250 --> 05:08.730 align:middle line:90%
And then it would forward
just the original IP packet

132
05:08.730 --> 05:11.680 align:middle line:84%
and payload going over to PC2.

133
05:11.680 --> 05:14.910 align:middle line:90%
So the benefit is with GRE,
we now have a network address,

134
05:14.910 --> 05:17.380 align:middle line:90%
we can support multiple
protocols, not just IP,

135
05:17.380 --> 05:20.712 align:middle line:90%
and we can support
multicast and broadcast.

136
05:20.712 --> 05:22.170 align:middle line:90%
And those facts
along with the fact

137
05:22.170 --> 05:24.360 align:middle line:90%
that we have an IP
network address associated

138
05:24.360 --> 05:27.750 align:middle line:90%
with this tunnel, we can use
dynamic routing protocols.

139
05:27.750 --> 05:32.010 align:middle line:90%
So R2 and R1 over this tunnel
could become OSPF neighbors
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

139
05:27.750 --> 05:32.010 align:middle line:90%
So R2 and R1 over this tunnel
could become OSPF neighbors

140
05:32.010 --> 05:34.890 align:middle line:90%
or EIGRP neighbors, and
share routing information

141
05:34.890 --> 05:38.032 align:middle line:90%
about their internal networks,
10.1 and 10.2 respectively.

142
05:38.032 --> 05:39.490 align:middle line:90%
Now the challenge
with that is that

143
05:39.490 --> 05:42.180 align:middle line:90%
generic routing
encapsulation by itself

144
05:42.180 --> 05:44.550 align:middle line:90%
doesn't do any type of
protecting the data.

145
05:44.550 --> 05:45.300 align:middle line:84%
No encryption.

146
05:45.300 --> 05:48.000 align:middle line:90%
So here is the final nail in
the coffin to get it all done.

147
05:48.000 --> 05:50.790 align:middle line:90%
We use GRE, we build that
tunnel between the two peers,

148
05:50.790 --> 05:54.480 align:middle line:90%
and then what we do is we
encrypt the GRE traffic

149
05:54.480 --> 05:55.800 align:middle line:84%
with IPSec.

150
05:55.800 --> 05:58.110 align:middle line:90%
And that's why it's
called GRE, like going

151
05:58.110 --> 06:00.480 align:middle line:90%
over that internal network
or that public network
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

151
05:58.110 --> 06:00.480 align:middle line:90%
over that internal network
or that public network

152
06:00.480 --> 06:03.810 align:middle line:90%
inside of an IPSec
encapsulated packet.

153
06:03.810 --> 06:05.940 align:middle line:90%
So the concept is
GRE over IPSec--

154
06:05.940 --> 06:08.820 align:middle line:90%
the benefits of GRE and
the protection of IPSec

155
06:08.820 --> 06:10.300 align:middle line:84%
all boiled into one.

156
06:10.300 --> 06:11.550 align:middle line:84%
So here's what I'd like to do.

157
06:11.550 --> 06:13.800 align:middle line:90%
In the next video, let you
and I sit down for a moment

158
06:13.800 --> 06:16.050 align:middle line:90%
and let's just make a plan
regarding what addresses

159
06:16.050 --> 06:17.462 align:middle line:84%
we want to use for the tunnels.

160
06:17.462 --> 06:19.170 align:middle line:90%
And we'll plan it all
out, and then we'll

161
06:19.170 --> 06:22.103 align:middle line:90%
proceed to implement the GRE and
verify it one step at a time.

162
06:22.103 --> 06:23.520 align:middle line:90%
And then as we
progress what we'll

163
06:23.520 --> 06:26.220 align:middle line:90%
do is once we get the GRE
tunnel in and working,

164
06:26.220 --> 06:29.907 align:middle line:90%
we'll then overlay on top of
that the IPSec protection.

165
06:29.907 --> 06:31.990 align:middle line:90%
So I look forward to seeing
you in the next video.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

165
06:29.907 --> 06:31.990 align:middle line:90%
So I look forward to seeing
you in the next video.

166
06:31.990 --> 06:34.290 align:middle line:90%
Meanwhile, I hope this has
been informative for you.

167
06:34.290 --> 06:37.460 align:middle line:90%
And I'd like to thank
you for viewing.