WEBVTT

1
00:00.000 --> 00:05.680
So we have now built out a software defined access fabric.

2
00:05.680 --> 00:12.090
We have our fabric edge nodes here and these edge nodes are going to play host

3
00:12.090 --> 00:14.000
to the subnets

4
00:14.000 --> 00:15.960
that exist in our normal network.

5
00:15.960 --> 00:21.080
Remember the edge nodes are going to be the access layer switches.

6
00:21.080 --> 00:25.790
So in our access closets we now have edge switches and these are now connecting

7
00:25.790 --> 00:26.400
to one another

8
00:26.400 --> 00:29.760
via a layer 3 underlay.

9
00:29.760 --> 00:35.830
And so a packet now shows up keeping in mind that we are talking about
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

9
00:29.760 --> 00:35.830
And so a packet now shows up keeping in mind that we are talking about

10
00:35.830 --> 00:37.760
potentially extending

11
00:37.760 --> 00:43.070
subnets among our different access closets just like we do in a traditional

12
00:43.070 --> 00:44.840
layer 2 design.

13
00:44.840 --> 00:51.430
And so we might have a packet from host A destined for host B and they're on

14
00:51.430 --> 00:53.000
the same subnet.

15
00:53.000 --> 00:58.400
Maybe this is 10 to 100 to 0 to 0/24.

16
00:58.400 --> 01:05.110
So if now our destination is for a host that is not attached to this edge
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

16
00:58.400 --> 01:05.110
So if now our destination is for a host that is not attached to this edge

17
01:05.110 --> 01:06.120
device, further

18
01:06.120 --> 01:11.160
more it is going to be connected to a device that is layer 3 segmented on the

19
01:11.160 --> 01:11.920
other side

20
01:11.920 --> 01:13.440
of this fabric.

21
01:13.440 --> 01:19.540
So the question is how does it know where to send this packet, the packet that

22
01:19.540 --> 01:20.480
just arrived

23
01:20.480 --> 01:25.430
on its downstream interface, it needs to know where to send this packet and

24
01:25.430 --> 01:26.000
there could

25
01:26.000 --> 01:31.240
be dozens of other edge devices that are out here.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

25
01:26.000 --> 01:31.240
be dozens of other edge devices that are out here.

26
01:31.240 --> 01:33.560
So it could be any one of these other edge switches.

27
01:33.560 --> 01:36.920
Do we just send it to all of them and hope for the best?

28
01:36.920 --> 01:41.850
Certainly I suppose that would be an option but it wouldn't be a very efficient

29
01:41.850 --> 01:42.400
one.

30
01:42.400 --> 01:47.970
Now when we think about forwarding decisions, if we want to forward traffic in

31
01:47.970 --> 01:49.080
a traditional

32
01:49.080 --> 01:52.760
network, how do we do this?

33
01:52.760 --> 01:57.840
Well in a traditional layer 3 environment, I need routes.

34
01:57.840 --> 02:00.920
I need routes everywhere.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

34
01:57.840 --> 02:00.920
I need routes everywhere.

35
02:00.920 --> 02:05.120
And in a lot of our organizational routing tables, we're going to find that we

36
02:05.120 --> 02:05.920
rely heavily

37
02:05.920 --> 02:11.620
on a default route because the default route will tell me what to do if I don't

38
02:11.620 --> 02:12.240
happen

39
02:12.240 --> 02:15.320
to have a more specific route.

40
02:15.320 --> 02:21.900
So this is important because if we think about it, this can amount to a lot of

41
02:21.900 --> 02:22.600
routes

42
02:22.600 --> 02:26.360
in the routing table.

43
02:26.360 --> 02:31.410
Now in an organizational subnet, we might have a few hundred, maybe dozens,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

43
02:26.360 --> 02:31.410
Now in an organizational subnet, we might have a few hundred, maybe dozens,

44
02:31.410 --> 02:32.760
maybe hundreds,

45
02:32.760 --> 02:38.400
maybe thousands of routes or subnets in the routing table.

46
02:38.400 --> 02:40.440
But look at what just happened.

47
02:40.440 --> 02:43.160
We now have a shared subnet.

48
02:43.160 --> 02:47.720
I'm not talking about knowing just where this slash 24 is.

49
02:47.720 --> 02:53.040
Yeah I can learn a lot of slash 24 and still manage that just fine on a switch.

50
02:53.040 --> 02:56.080
I need to know where this host is.

51
02:56.080 --> 03:01.080
This host is effectively a slash 32 route.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

51
02:56.080 --> 03:01.080
This host is effectively a slash 32 route.

52
03:01.080 --> 03:07.670
And if I have a subnet like a slash 24, I might have 250 slash 32 hosts

53
03:07.670 --> 03:08.880
throughout this

54
03:08.880 --> 03:13.080
network and that's going to be true for every one of my subnets.

55
03:13.080 --> 03:18.600
So does this architecture scale particularly well and the answer is no.

56
03:18.600 --> 03:22.320
I don't necessarily want to have routes everywhere.

57
03:22.320 --> 03:26.240
First of all, if we're talking about knowing where all these slash 32 routes

58
03:26.240 --> 03:27.120
are, a default

59
03:27.120 --> 03:28.920
route isn't going to help me.

60
03:28.920 --> 03:34.170
I'm not going to be able to just forward it to let's say this edge node up here
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

60
03:28.920 --> 03:34.170
I'm not going to be able to just forward it to let's say this edge node up here

61
03:34.170 --> 03:34.280
, call

62
03:34.280 --> 03:36.800
that my default route and hope for the best.

63
03:36.800 --> 03:42.910
Now I have to forward to this specific edge node so it can get to this specific

64
03:42.910 --> 03:43.720
host.

65
03:43.720 --> 03:49.220
That means that I need to in theory based on traditional networking, routing

66
03:49.220 --> 03:50.280
and switching,

67
03:50.280 --> 03:55.120
I would need to know where every single slash 32 in the network is.

68
03:55.120 --> 04:00.240
This is a push methodology.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

68
03:55.120 --> 04:00.240
This is a push methodology.

69
04:00.240 --> 04:05.000
I would push all of these routes everywhere in the network.

70
04:05.000 --> 04:07.480
And this is how our networks today work.

71
04:07.480 --> 04:12.240
If I have a traditional layer three architecture, I'm going to run something

72
04:12.240 --> 04:15.120
like OSPF or EIGRP

73
04:15.120 --> 04:19.000
and I am proactively pushing subnet information everywhere.

74
04:19.000 --> 04:25.050
So unless I'm going to rely on a default route, I now have all of the routes in

75
04:25.050 --> 04:26.520
my environment.

76
04:26.520 --> 04:32.040
And so this works well again at the scale that most of our organizations work
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

76
04:26.520 --> 04:32.040
And so this works well again at the scale that most of our organizations work

77
04:32.040 --> 04:32.600
on.

78
04:32.600 --> 04:35.660
And now that we're talking about learning potentially where every single host

79
04:35.660 --> 04:36.200
lives in the

80
04:36.200 --> 04:40.600
environment, we're going to have some massive scaling issues.

81
04:40.600 --> 04:45.600
It's going to require us to have a lot of slash 32 routes.

82
04:45.600 --> 04:49.810
So rather than use this push methodology of saying everyone's going to know

83
04:49.810 --> 04:50.680
where all of

84
04:50.680 --> 04:53.440
the routes are, we're going to switch this over.

85
04:53.440 --> 05:02.960
And we're going to have a poll methodology where we can learn our routes on an
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

85
04:53.440 --> 05:02.960
And we're going to have a poll methodology where we can learn our routes on an

86
05:02.960 --> 05:07.480
as needed basis.

87
05:07.480 --> 05:12.800
This means that until a packet shows up destined for host B, I'm not going to

88
05:12.800 --> 05:14.040
know where B lives.

89
05:14.040 --> 05:17.900
I don't need to proactively have that information, along with the thousands of

90
05:17.900 --> 05:18.640
other hosts in my

91
05:18.640 --> 05:23.560
network, I just need to know where to learn.

92
05:23.560 --> 05:30.040
And I'm going to rely on a database of information in order to learn where that
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

92
05:23.560 --> 05:30.040
And I'm going to rely on a database of information in order to learn where that

93
05:30.040 --> 05:30.640
is.

94
05:30.640 --> 05:36.420
This whole mechanism set is going to rely on a protocol known as the locator ID

95
05:36.420 --> 05:37.320
separator

96
05:37.320 --> 05:40.520
protocol or Lisp.

97
05:40.520 --> 05:45.210
Lisp is a Cisco proprietary protocol and it was developed for the service

98
05:45.210 --> 05:47.400
provider space.

99
05:47.400 --> 05:52.140
And here we are saying, you know what, we can also apply this to software

100
05:52.140 --> 05:53.480
defined access.

101
05:53.480 --> 05:58.970
What we need is we need a database, a database that can sit here accessible in

102
05:58.970 --> 06:00.080
the underlay,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

102
05:58.970 --> 06:00.080
the underlay,

103
06:00.080 --> 06:03.560
so accessible by all of these edge devices.

104
06:03.560 --> 06:13.640
And that database needs to know all of the host to edge mappings.

105
06:13.640 --> 06:18.110
This edge that we're talking about here, this edge device, where we're really

106
06:18.110 --> 06:18.760
saying is

107
06:18.760 --> 06:24.420
I need an IP address that I can tell everyone, hey, if you want to get to a

108
06:24.420 --> 06:25.840
particular host,

109
06:25.840 --> 06:31.120
like host B, send it to this edge's loopback IP address.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

109
06:25.840 --> 06:31.120
like host B, send it to this edge's loopback IP address.

110
06:31.120 --> 06:38.280
This IP address in the Lisp world is known as a routing locator or an R lock.

111
06:38.280 --> 06:44.440
So basically if this edge device has an IP address of 10.1.1.1, then our

112
06:44.440 --> 06:45.640
database is going

113
06:45.640 --> 06:52.800
to say that if we have a packet destined for host B, that we should send it to

114
06:52.800 --> 06:55.960
10.1.1.1.

115
06:55.960 --> 07:00.020
This is the mapping that we're talking about here of saying that a host address
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

115
06:55.960 --> 07:00.020
This is the mapping that we're talking about here of saying that a host address

116
07:00.020 --> 07:00.840
, the slash

117
07:00.840 --> 07:08.440
32 route, is mapped to a specific R lock or ultimately a specific fabric edge

118
07:08.440 --> 07:09.320
node.

119
07:09.320 --> 07:14.640
In Lisp, this database is known as a map server or a map resolver.

120
07:14.640 --> 07:18.800
And we're going to cover a lot more about Lisp in greater details later on in

121
07:18.800 --> 07:19.840
this course.

122
07:19.840 --> 07:23.180
But for now, just some Lisp terms are being tossed around here, like the R lock

123
07:23.180 --> 07:23.920
is the IP

124
07:23.920 --> 07:24.920
address.

125
07:24.920 --> 07:30.450
The map server, map resolver is this database concept and in our SDA
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

125
07:24.920 --> 07:30.450
The map server, map resolver is this database concept and in our SDA

126
07:30.450 --> 07:31.680
environment, we're

127
07:31.680 --> 07:35.760
going to refer to this as the control plane node.

128
07:35.760 --> 07:39.800
And that is exactly what this device is here in the fabric.

129
07:39.800 --> 07:45.520
This database is our CP node in the SDA architecture.

130
07:45.520 --> 07:48.360
So back to the original scenario.

131
07:48.360 --> 07:53.730
We had said that host A sends a packet with a destination address of B. And it

132
07:53.730 --> 07:53.920
lands

133
07:53.920 --> 07:57.480
on this fabric edge and it says, I don't know where B is.

134
07:57.480 --> 08:01.360
And that's because we're not proactively pushing that information to the edge.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

134
07:57.480 --> 08:01.360
And that's because we're not proactively pushing that information to the edge.

135
08:01.360 --> 08:07.210
So instead, this edge has to go out and send a request to say, hey, I'd like to

136
08:07.210 --> 08:08.760
know where

137
08:08.760 --> 08:09.760
host B lives.

138
08:09.760 --> 08:12.400
I'm going to get my answer here.

139
08:12.400 --> 08:14.280
And this is why we call this a pole methodology.

140
08:14.280 --> 08:20.040
I'm pulling this information down from the map server, the map resolver, the

141
08:20.040 --> 08:20.760
control

142
08:20.760 --> 08:25.560
plane node, whatever one of all this database and SDA terms is the control

143
08:25.560 --> 08:26.600
plane node.

144
08:26.600 --> 08:29.760
So I'm going to pull that information down from the control plane node.

145
08:29.760 --> 08:34.360
And now I know that I'm supposed to send it over here to this edge node.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

145
08:29.760 --> 08:34.360
And now I know that I'm supposed to send it over here to this edge node.

146
08:34.360 --> 08:39.960
The problem is I now need to send it to that edge node.

147
08:39.960 --> 08:45.260
But if the destination in my packet is this host, how do I send it to a

148
08:45.260 --> 08:47.520
different destination?

149
08:47.520 --> 08:50.520
While second destination is going to require a tunnel.

150
08:50.520 --> 08:56.570
I need to build a tunnel between edge nodes here so that my actual destination

151
08:56.570 --> 08:58.320
is this device

152
08:58.320 --> 08:59.880
in the outer header.

153
08:59.880 --> 09:02.520
But this tunnel can't just be any tunnel mechanism.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

153
08:59.880 --> 09:02.520
But this tunnel can't just be any tunnel mechanism.

154
09:02.520 --> 09:07.830
It needs to carry this layer to information since we are stretching this subnet

155
09:07.830 --> 09:08.120
between

156
09:08.120 --> 09:09.920
the two locations.

157
09:09.920 --> 09:14.800
And so in the next video, we're going to explore how we can leverage VXLAN in

158
09:14.800 --> 09:15.400
order to make

159
09:15.400 --> 09:17.080
this tunnel mechanism happen.

160
09:17.080 --> 09:27.080
[BLANK_AUDIO]