WEBVTT

1
00:00.000 --> 00:04.520
We've looked at how software defined access handles traffic flow, but we've

2
00:04.520 --> 00:09.360
made an assumption this whole time that the hosts were already known. So let's

3
00:09.360 --> 00:14.160
remember how this works. We have a fabric edge node here on the left. We have a

4
00:14.160 --> 00:18.840
fabric edge node here on the right. We have a packet coming in from one

5
00:18.840 --> 00:19.320
endpoint.

6
00:19.320 --> 00:25.600
We'll call this endpoint 1 here, coming in on FE1 and then endpoint 2 on the

7
00:25.600 --> 00:32.880
right connected to FE2. And so what we have is we have a frame that is getting
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

7
00:25.600 --> 00:32.880
right connected to FE2. And so what we have is we have a frame that is getting

8
00:32.880 --> 00:42.200
sent out sourced from endpoint 1 destined for endpoint 2. And so we know

9
00:42.200 --> 00:46.920
that we need to understand where endpoint 2 is. Fabric edge node 1

10
00:46.920 --> 00:51.840
doesn't necessarily know this. Maybe it already has it cached, but let's just

11
00:51.840 --> 00:57.160
assume it doesn't. So we're going to go to the control plane node. The control

12
00:57.160 --> 01:02.600
plane node is a Cisco device that is going to maintain the mappings. Remember
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

12
00:57.160 --> 01:02.600
plane node is a Cisco device that is going to maintain the mappings. Remember

13
01:02.600 --> 01:08.000
of our endpoint IDs that map to the routing locator. So this EID to R-lock

14
01:08.000 --> 01:12.880
mapping. And these are a bunch of Lisp terms because that's what we're using at

15
01:12.880 --> 01:19.570
the control plane. So FE1 fabric edge node 1 is going to send the map request

16
01:19.570 --> 01:20.040
to

17
01:20.040 --> 01:24.000
the control plane node. We're going to get a map reply back that says, hey, if

18
01:24.000 --> 01:30.840
you're trying to get to endpoint 2, try sending to fabric edge 2. Now keep in
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

18
01:24.000 --> 01:30.840
you're trying to get to endpoint 2, try sending to fabric edge 2. Now keep in

19
01:30.840 --> 01:35.860
mind that within the SD access world, this response might actually get

20
01:35.860 --> 01:36.680
redirected

21
01:36.680 --> 01:41.840
and the response comes from over here to say that FE2 directly responds and

22
01:41.840 --> 01:46.800
says that it has endpoint 2. It depends on how we configure our SD access

23
01:46.800 --> 01:50.840
environment. But either way, now this question mark becomes, I guess, an

24
01:50.840 --> 01:57.320
exclamation point, and FE1 fabric edge node 1 now knows where endpoint 2 is.

25
01:57.320 --> 02:04.400
Now again, we're going to record this in cache and say that endpoint 2 is
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

25
01:57.320 --> 02:04.400
Now again, we're going to record this in cache and say that endpoint 2 is

26
02:04.400 --> 02:04.800
mapped

27
02:04.800 --> 02:11.760
to the routing locator for fabric edge 2. So this cache is going to keep that

28
02:11.760 --> 02:12.000
in

29
02:12.000 --> 02:18.010
mind for up to 24 hours. So the assumption here is that outside of wireless

30
02:18.010 --> 02:18.320
roaming,

31
02:18.320 --> 02:22.040
and we'll talk about wireless roaming later, but outside of that endpoint 2

32
02:22.040 --> 02:25.960
probably isn't going to be moving around a whole lot. A lot of our wired

33
02:25.960 --> 02:30.960
clients and wireless stations don't actually move. And so keeping this cache
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

33
02:25.960 --> 02:30.960
clients and wireless stations don't actually move. And so keeping this cache

34
02:30.960 --> 02:37.640
for 24 hours is usually considered to be pretty safe. And if it does move for

35
02:37.640 --> 02:37.680
any

36
02:37.680 --> 02:43.960
reason, then we will update the cache. And that's all handled by the fabric, no

37
02:43.960 --> 02:47.560
problem. But the idea here is we don't want to have to go through the whole

38
02:47.560 --> 02:52.440
control plane process just to learn where this endpoint is. And so every time

39
02:52.440 --> 02:57.480
another frame shows up destined for endpoint 2, this cache entry is going to

40
02:57.480 --> 03:04.800
get reset. So remember, it's 24 hours of inactivity, not after 24 hours of
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

40
02:57.480 --> 03:04.800
get reset. So remember, it's 24 hours of inactivity, not after 24 hours of

41
03:04.800 --> 03:08.560
initially learning it. At that point, we would drop the entry from the cache,

42
03:08.560 --> 03:13.080
because probably maybe that endpoint dropped off the network. And so we

43
03:13.080 --> 03:16.440
shouldn't assume that it's still there. If nobody's tried talking to it for

44
03:16.440 --> 03:22.160
again, 24 hours. So at this point, we understand that we are going to use that

45
03:22.160 --> 03:27.760
VX land tunnel between our fabric edge nodes, we're going to encapsulate it,

46
03:27.760 --> 03:32.360
send that frame over to fabric edge 2, and then it will get delivered. And that
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

46
03:27.760 --> 03:32.360
send that frame over to fabric edge 2, and then it will get delivered. And that

47
03:32.360 --> 03:38.600
is how our fabric traffic flow works. But here's the question that we want to

48
03:38.600 --> 03:45.000
ask, where did this entry come from? How does the control plane node know where

49
03:45.000 --> 03:50.160
endpoint 2 is? And so we need to understand that there is a registration

50
03:50.160 --> 03:57.040
process involved. Now, there is a few other Lisp terms to be aware of. First of

51
03:57.040 --> 04:02.640
all, we have the ingress tunneling router or the ITR. And then we have the e
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

51
03:57.040 --> 04:02.640
all, we have the ingress tunneling router or the ITR. And then we have the e

52
04:02.640 --> 04:03.000
gress

53
04:03.000 --> 04:07.560
tunneling router or the ETR. The key focus here is not on the word router,

54
04:07.560 --> 04:11.960
because these are probably catalyst 9K switches in our fabric environment. And

55
04:11.960 --> 04:16.280
so again, Lisp was developed for the internet. And so we have this router word

56
04:16.280 --> 04:21.560
that we are trying to apply to switches. The focus instead should be on the I,

57
04:21.560 --> 04:32.040
which stands for ingress, and the E, which stands for egress. The word ingress
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

57
04:21.560 --> 04:32.040
which stands for ingress, and the E, which stands for egress. The word ingress

58
04:32.040 --> 04:32.280
is

59
04:32.280 --> 04:37.600
referring to the fact that it's coming into the fabric, and the word egress is

60
04:37.600 --> 04:43.640
saying we're coming out of the fabric. So that's interesting, because if I were

61
04:43.640 --> 04:49.160
to send a response frame from endpoint 2 back to endpoint 1, I'm coming into

62
04:49.160 --> 04:49.280
the

63
04:49.280 --> 04:53.760
fabric on this side and coming out of the fabric the other way, and that is

64
04:53.760 --> 04:54.040
true.

65
04:54.040 --> 05:01.440
The phrase and term ITR and ETR, these are relative terms relative to the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

65
04:54.040 --> 05:01.440
The phrase and term ITR and ETR, these are relative terms relative to the

66
05:01.440 --> 05:06.040
specific traffic flow we're talking about. Meaning if endpoint 1 is talking to

67
05:06.040 --> 05:11.480
endpoint 2, ITR and ETR as we have labeled. If it's going the other way, then

68
05:11.480 --> 05:11.680
now

69
05:11.680 --> 05:19.920
Fe2 operates as the I, I, T, R, and Fe1 operates as the E, T, R. So they can go

70
05:19.920 --> 05:26.960
both directions and oftentimes they do. And so we will also see these referred

71
05:26.960 --> 05:27.160
to

72
05:27.160 --> 05:34.720
as XTRs, just meaning that they do both functions. So why do we bring this up?
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

72
05:27.160 --> 05:34.720
as XTRs, just meaning that they do both functions. So why do we bring this up?

73
05:34.720 --> 05:40.760
Well, because this endpoint 2 is attaching to a particular device, and because

74
05:40.760 --> 05:46.680
endpoint 2 is going to be targeted by other communications, we typically are

75
05:46.680 --> 05:52.340
referring to its attached device as its ETR, because the rest of the network

76
05:52.340 --> 05:52.520
needs

77
05:52.520 --> 05:57.440
to know where it is. But again, we can think of it in whatever terms we want,

78
05:57.440 --> 06:01.880
just be aware that endpoint 2 is going to have a device that it's attaching to.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

78
05:57.440 --> 06:01.880
just be aware that endpoint 2 is going to have a device that it's attaching to.

79
06:01.880 --> 06:09.480
So in our case, with the ITR and the ETR set, we have to keep in mind a few

80
06:09.480 --> 06:14.360
things. First of all, remember that on ingress, our frames are going to get put

81
06:14.360 --> 06:18.960
into the into the VXLAN world and that VXLAN headers going to carry some

82
06:18.960 --> 06:25.450
important information. For example, it's going to have the tagged policy on ing

83
06:25.450 --> 06:25.920
ress.

84
06:25.920 --> 06:31.480
And if we think back to that policy plane type of model, this is going to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

84
06:25.920 --> 06:31.480
And if we think back to that policy plane type of model, this is going to

85
06:31.480 --> 06:37.800
involve a scalable group tag, as well as a virtual network identifier. And so

86
06:37.800 --> 06:38.080
the

87
06:38.080 --> 06:43.200
this ties back to the scalable groups and the virtual networks, which are

88
06:43.200 --> 06:47.590
essentially VRFs for macro segmentation and scalable groups for micro segment

89
06:47.590 --> 06:48.000
ation.

90
06:48.000 --> 06:52.920
But remember, we're not enforcing the security policy here. The enforcement

91
06:52.920 --> 06:58.440
happens here on egress. So our policy enforcement is going to be the

92
06:58.440 --> 07:06.160
responsibility of the ETR. Furthermore, it's this device over on the right. In
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

92
06:58.440 --> 07:06.160
responsibility of the ETR. Furthermore, it's this device over on the right. In

93
07:06.160 --> 07:06.360
our

94
07:06.360 --> 07:13.640
case, again, the ETR that is responsible for identifying and registering the

95
07:13.640 --> 07:20.480
attached endpoints. So one of the key parts of this conversation is how does

96
07:20.480 --> 07:25.400
the control plane know where to find all of these different endpoints? How does

97
07:25.400 --> 07:30.520
it know that these endpoint IDs are mapped to specific R locks? Well, that is
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

97
07:25.400 --> 07:30.520
it know that these endpoint IDs are mapped to specific R locks? Well, that is

98
07:30.520 --> 07:36.030
the responsibility of this device here. Again, the ETR in our scenario. And it

99
07:36.030 --> 07:36.200
's

100
07:36.200 --> 07:44.320
going to perform a map register operation by sending a packet to the control

101
07:44.320 --> 07:44.600
plane

102
07:44.600 --> 07:50.560
node. It's letting it know that, Hey, I have a new endpoint identifier. And in

103
07:50.560 --> 07:50.720
our

104
07:50.720 --> 07:58.470
case, in the SDA world, this is typically going to be a slash 32 route. We can

105
07:58.470 --> 07:58.600
't

106
07:58.600 --> 08:04.440
advertise the slash 24 route because in SD access, we've got the same subnets
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

106
07:58.600 --> 08:04.440
advertise the slash 24 route because in SD access, we've got the same subnets

107
08:04.440 --> 08:09.680
everywhere. We could have dozens of other fabric edge nodes. And they all have

108
08:09.680 --> 08:14.840
this exact same subnet, because it's our access layer inside of our campus. And

109
08:14.840 --> 08:15.040
so

110
08:15.040 --> 08:21.760
we can't share the slash 24 route that shared everywhere. But rather, we want

111
08:21.760 --> 08:21.840
to

112
08:21.840 --> 08:25.640
share the specific endpoint identifier. And so that's why we're advertising

113
08:25.640 --> 08:31.120
slash 32 routes to the control plane node. So this completes the picture at
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

113
08:25.640 --> 08:31.120
slash 32 routes to the control plane node. So this completes the picture at

114
08:31.120 --> 08:36.920
this point, we would find that a new ITR, maybe down here, a packet arrives.

115
08:36.920 --> 08:37.360
This

116
08:37.360 --> 08:42.840
is now our ITR for this particular traffic flow. And it needs to know where

117
08:42.840 --> 08:48.960
endpoint two is. And so now it's going to send its own map request message to

118
08:48.960 --> 08:49.040
the

119
08:49.040 --> 08:53.080
control plane node, it'll get a map response back from somebody, neither the

120
08:53.080 --> 08:58.520
control plane node or fabric edge to. But because the control plane node now

121
08:58.520 --> 09:03.680
knows where this attached endpoint lives, it can respond back. And that's
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

121
08:58.520 --> 09:03.680
knows where this attached endpoint lives, it can respond back. And that's

122
09:03.680 --> 09:04.000
thanks

123
09:04.000 --> 09:08.680
to the map register message that was sent, once that packet first or once that

124
09:08.680 --> 09:11.320
endpoint first attached to the fabric.

125
09:11.320 --> 09:29.880
[no audio]