WEBVTT

1
00:00.000 --> 00:04.630
In a lot of cases, we are going to be focused on things from an organizational

2
00:04.630 --> 00:05.320
perspective,

3
00:05.320 --> 00:07.760
meaning that I have a single network.

4
00:07.760 --> 00:13.340
I may be responsible for the network for my one organization and I have to

5
00:13.340 --> 00:14.240
connect my

6
00:14.240 --> 00:17.360
many organizational sites to one another.

7
00:17.360 --> 00:21.540
But things change when we think about this from a service provider perspective,

8
00:21.540 --> 00:21.680
because

9
00:21.680 --> 00:27.270
at this point I have a multi-tenancy environment, which is a really fancy way

10
00:27.270 --> 00:28.280
of saying that

11
00:28.280 --> 00:33.840
I have many networks, not just a single one.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

11
00:28.280 --> 00:33.840
I have many networks, not just a single one.

12
00:33.840 --> 00:38.680
This is kind of a big deal because I need to make sure that these many networks

13
00:38.680 --> 00:39.060
stay

14
00:39.060 --> 00:42.560
separated from one another.

15
00:42.560 --> 00:46.120
If I don't keep them separated, there we go.

16
00:46.120 --> 00:50.440
If I don't keep them separated, then the traffic will start to inter-mix.

17
00:50.440 --> 00:53.830
And we definitely don't want that if we've got many customers, those customers

18
00:53.830 --> 00:54.560
are expecting

19
00:54.560 --> 00:58.800
to not see their traffic get crossed over into one another.

20
00:58.800 --> 01:06.440
And so built in to Cisco SD-WAN is the concept of multi-tenancy.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

20
00:58.800 --> 01:06.440
And so built in to Cisco SD-WAN is the concept of multi-tenancy.

21
01:06.440 --> 01:13.240
And the way we build a multi-tenant environment is with VPNs.

22
01:13.240 --> 01:18.210
Now, I don't know about you, but when I think about VPNs, I think about remote

23
01:18.210 --> 01:19.120
connectivity

24
01:19.120 --> 01:24.400
into my organization's network, maybe a site to site, kind of VPN.

25
01:24.400 --> 01:28.640
That's not really what we mean by SD-WAN VPNs.

26
01:28.640 --> 01:35.000
Instead, an SD-WAN VPN really more parallels a virtual routing and forwarding
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

26
01:28.640 --> 01:35.000
Instead, an SD-WAN VPN really more parallels a virtual routing and forwarding

27
01:35.000 --> 01:35.840
instance

28
01:35.840 --> 01:36.840
or a VRF.

29
01:36.840 --> 01:43.180
A VRF is sort of like taking a layer 3 device and carving it up into multiple

30
01:43.180 --> 01:45.000
layer 3 domains.

31
01:45.000 --> 01:49.040
And this is heavily used with multi-tenancy to allow me to have multiple

32
01:49.040 --> 01:50.040
routing tables

33
01:50.040 --> 01:53.000
and basically a routing table per customer.

34
01:53.000 --> 01:55.840
So let's take a look at a topology here.

35
01:55.840 --> 01:59.440
Let's say that, again, think about it, things from a service provider.

36
01:59.440 --> 02:04.950
I have a WAN Edge device here and I have a WAN Edge device here and I build out
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

36
01:59.440 --> 02:04.950
I have a WAN Edge device here and I have a WAN Edge device here and I build out

37
02:04.950 --> 02:05.640
my service

38
02:05.640 --> 02:07.680
provider network.

39
02:07.680 --> 02:10.360
Maybe this is an MPLS domain.

40
02:10.360 --> 02:15.760
And I'm going to make sure that I build my IPsec tunnel from WAN Edge to WAN

41
02:15.760 --> 02:17.880
Edge here.

42
02:17.880 --> 02:19.120
So that's great.

43
02:19.120 --> 02:24.420
However, now because I'm a service provider, I actually have a customer A

44
02:24.420 --> 02:25.420
network here

45
02:25.420 --> 02:29.720
and a customer A network hanging off of this other WAN Edge.

46
02:29.720 --> 02:36.240
But then from there, I also have a customer B network hanging off as well.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

46
02:29.720 --> 02:36.240
But then from there, I also have a customer B network hanging off as well.

47
02:36.240 --> 02:41.590
Now as we can imagine, I don't want my customer B to be able to send traffic in

48
02:41.590 --> 02:42.160
and number

49
02:42.160 --> 02:45.760
one, go locally to another organization.

50
02:45.760 --> 02:50.380
And number two, be able to forward across this IPsec tunnel and also end up

51
02:50.380 --> 02:51.120
going into

52
02:51.120 --> 02:52.440
the other organization.

53
02:52.440 --> 02:56.190
That's a security breach from both customers' perspectives and we need to

54
02:56.190 --> 02:57.080
prevent this no

55
02:57.080 --> 02:58.880
matter what.

56
02:58.880 --> 03:00.320
So here's what we're going to do.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

56
02:58.880 --> 03:00.320
So here's what we're going to do.

57
03:00.320 --> 03:06.470
We are going to embrace the concept of VPNs and so I'm going to say customer A,

58
03:06.470 --> 03:07.080
let's

59
03:07.080 --> 03:11.560
say, is going to use VPN 10 and customer VB.

60
03:11.560 --> 03:14.960
We'll use VPN 20.

61
03:14.960 --> 03:18.040
So we're using two different VPNs at this point.

62
03:18.040 --> 03:23.920
What we do is we place these interfaces into their respective VPNs.

63
03:23.920 --> 03:28.120
And again, the more we parallel this back to VRFs, the more this is going to

64
03:28.120 --> 03:28.800
track.

65
03:28.800 --> 03:32.680
Because this is exactly what we do for VRF configuration as well.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

65
03:28.800 --> 03:32.680
Because this is exactly what we do for VRF configuration as well.

66
03:32.680 --> 03:37.390
Furthermore, as traffic gets put into the same tunnel and yes, they do share

67
03:37.390 --> 03:38.280
the tunnel,

68
03:38.280 --> 03:44.760
they are going to be distinguished within the tunnel with the VPN identifiers.

69
03:44.760 --> 03:49.240
In other words, we don't want to allow the router on the other side to receive

70
03:49.240 --> 03:50.080
traffic and

71
03:50.080 --> 03:55.520
say, hey, this packet just arrived is this part of a VPN?

72
03:55.520 --> 03:57.160
Is it on VPN 10?

73
03:57.160 --> 03:58.960
Is it on VPN 20?

74
03:58.960 --> 04:03.080
We're going to know that because the traffic carries the VPN ID.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

74
03:58.960 --> 04:03.080
We're going to know that because the traffic carries the VPN ID.

75
04:03.080 --> 04:04.360
So it's no longer a question.

76
04:04.360 --> 04:07.880
I know that this belongs to VPN 10.

77
04:07.880 --> 04:12.350
And so I'm not even going to consider the routing table of customer B here

78
04:12.350 --> 04:13.160
because that

79
04:13.160 --> 04:16.600
would be part of VPN 20.

80
04:16.600 --> 04:21.040
Now again, I do want to be clear that VPNs are very much a service provider

81
04:21.040 --> 04:22.120
technology.

82
04:22.120 --> 04:26.800
It's not something we're going to interact with a lot if I'm deploying SD WAN

83
04:26.800 --> 04:27.560
myself.

84
04:27.560 --> 04:31.120
So a lot of service providers I can go to and I can say, hey, I would like for
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

84
04:27.560 --> 04:31.120
So a lot of service providers I can go to and I can say, hey, I would like for

85
04:31.120 --> 04:31.800
you to manage

86
04:31.800 --> 04:36.080
my VPN or my VPN, my SD WAN environment.

87
04:36.080 --> 04:40.380
And maybe they even offer an SD WAN solution and their SD WAN solution is built

88
04:40.380 --> 04:41.360
on Cisco SD

89
04:41.360 --> 04:42.360
WAN.

90
04:42.360 --> 04:46.720
And they're using VPNs because all of their customers are sharing all of their

91
04:46.720 --> 04:47.960
WAN edge tunnels

92
04:47.960 --> 04:51.980
because they deploy these routers, these WAN edges out to places that can then

93
04:51.980 --> 04:52.520
connect

94
04:52.520 --> 04:54.880
to multiple organizations.

95
04:54.880 --> 04:59.570
So it makes sense from a service provider from a single organization

96
04:59.570 --> 05:00.800
perspective, do we
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

96
04:59.570 --> 05:00.800
perspective, do we

97
05:00.800 --> 05:02.480
still need to know this?

98
05:02.480 --> 05:03.480
The answer is yes.

99
05:03.480 --> 05:06.650
First of all, we need to understand the architecture because we're going to see

100
05:06.650 --> 05:08.000
VPN configuration

101
05:08.000 --> 05:09.800
when we're deploying SD WAN.

102
05:09.800 --> 05:13.410
So we do need to choose a VPN to represent our organization even if we're only

103
05:13.410 --> 05:13.920
going to

104
05:13.920 --> 05:15.320
use a single one.

105
05:15.320 --> 05:19.200
But there are also a few exceptions around VPNs that we need to be aware of,

106
05:19.200 --> 05:20.080
especially as

107
05:20.080 --> 05:25.640
it relates to the organization of VPN IDs.

108
05:25.640 --> 05:31.760
So the full VPN range, interestingly, I say interestingly because it's actually
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

108
05:25.640 --> 05:31.760
So the full VPN range, interestingly, I say interestingly because it's actually

109
05:31.760 --> 05:32.200
kind

110
05:32.200 --> 05:38.560
of interesting how this all comes together, but it ranges from zero to 65, 530.

111
05:38.560 --> 05:40.600
Think comes next.

112
05:40.600 --> 05:45.480
Usually we say 65, 535 because that's a full 16 bit number.

113
05:45.480 --> 05:48.760
But SD WAN ends with 65, 530.

114
05:48.760 --> 05:49.760
Don't ask me why.

115
05:49.760 --> 05:55.640
It was maybe they just wanted a few at the end for the sake of reserving some

116
05:55.640 --> 05:56.280
VPN IDs.

117
05:56.280 --> 06:00.060
But the reason that that's interesting is because they actually do reserve a
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

117
05:56.280 --> 06:00.060
But the reason that that's interesting is because they actually do reserve a

118
06:00.060 --> 06:01.440
couple of other

119
06:01.440 --> 06:02.440
IDs.

120
06:02.440 --> 06:11.540
Specifically VPN zero, this is used for the underlay or maybe we should say the

121
06:11.540 --> 06:15.100
WAN circuits.

122
06:15.100 --> 06:20.220
So when we're looking at a router and we just said that we've got an interface

123
06:20.220 --> 06:20.780
here in

124
06:20.780 --> 06:29.600
this interface on the service side, this is going to be a VPN of let's say 10.

125
06:29.600 --> 06:36.850
Well now I've got an IP address here on a circuit that goes to my MPLS provider
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

125
06:29.600 --> 06:36.850
Well now I've got an IP address here on a circuit that goes to my MPLS provider

126
06:36.850 --> 06:37.080
.

127
06:37.080 --> 06:42.390
Well this interface is going to be in VPN zero because it's part of the under

128
06:42.390 --> 06:43.000
lay.

129
06:43.000 --> 06:44.840
And so I can't change that.

130
06:44.840 --> 06:49.680
Furthermore, VPN 512 is also reserved.

131
06:49.680 --> 06:54.280
And this is reserved for out of band management.

132
06:54.280 --> 06:59.040
In other words, communications with our control plane and other devices.

133
06:59.040 --> 07:03.110
So our V-bonds and our V-Smarts and everything out there is going to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

133
06:59.040 --> 07:03.110
So our V-bonds and our V-Smarts and everything out there is going to

134
07:03.110 --> 07:06.400
communicate using VPN 512.

135
07:06.400 --> 07:12.160
And so this creates a rather interesting range of eligible VPN IDs.

136
07:12.160 --> 07:15.400
Because if we think about it, we can't use zero.

137
07:15.400 --> 07:17.040
So I'm going to start at one.

138
07:17.040 --> 07:18.840
And I can't use 512 either.

139
07:18.840 --> 07:23.080
And so I'm going to have to sort of comment here and say I can use 513 all the

140
07:23.080 --> 07:26.920
way up to 65530.

141
07:26.920 --> 07:28.960
Now why did this come about?

142
07:28.960 --> 07:31.800
Well there's a little bit of history behind this.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

142
07:28.960 --> 07:31.800
Well there's a little bit of history behind this.

143
07:31.800 --> 07:40.360
And long story short, the VPN range used to be historically zero to 512.

144
07:40.360 --> 07:46.900
And so Cisco and Viptela at the time reserved the first and last VPN ID from

145
07:46.900 --> 07:48.240
the range.

146
07:48.240 --> 07:52.200
And so that was well and good other than it was always a 16 bit value.

147
07:52.200 --> 07:56.580
And so we thought, well, why would we not use the full range, especially for

148
07:56.580 --> 07:58.080
service providers,

149
07:58.080 --> 08:03.000
that have more than 500 or so customers.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

149
07:58.080 --> 08:03.000
that have more than 500 or so customers.

150
08:03.000 --> 08:08.880
And so instead we extended we being Cisco extended the range out to the what

151
08:08.880 --> 08:09.480
they consider

152
08:09.480 --> 08:13.400
to be the max nearly the full 16 bit range.

153
08:13.400 --> 08:18.280
But because of the way the architecture had been built, 0 and 512 had already

154
08:18.280 --> 08:19.480
been reserved.

155
08:19.480 --> 08:29.120
So that is why 0 and 512 of all VPN IDs are not eligible to be used.

156
08:29.120 --> 08:32.980
So if you work for a single organization and you're just your own tenant, you
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

156
08:29.120 --> 08:32.980
So if you work for a single organization and you're just your own tenant, you

157
08:32.980 --> 08:33.480
can pick any

158
08:33.480 --> 08:37.080
of these VPN IDs to use in your environment.

159
08:37.080 --> 08:39.980
But if you're a service provider, you're going to find that you're going to be

160
08:39.980 --> 08:40.640
using many

161
08:40.640 --> 08:45.240
of these VPN IDs, each one representing one of your customers.

162
08:45.240 --> 08:55.240
[BLANK_AUDIO]