1
00:00:00,000 --> 00:00:00,980

2
00:00:00,980 --> 00:00:04,410
[AUDIO LOGO]

3
00:00:04,410 --> 00:00:07,840

4
00:00:07,840 --> 00:00:11,050
So now that we're starting
to get a better idea of how

5
00:00:11,050 --> 00:00:13,600
segment routing
operates, it's time

6
00:00:13,600 --> 00:00:18,550
to take a closer look at those
segment identifiers or SSIDs

7
00:00:18,550 --> 00:00:21,520
that we've been sort of talking
about as we've been going

8
00:00:21,520 --> 00:00:23,510
through the previous sections.

9
00:00:23,510 --> 00:00:27,310
We've already sort of addressed
prefix SSIDs a little bit.

10
00:00:27,310 --> 00:00:29,950
We've also mentioned
adjacency SSIDs.

11
00:00:29,950 --> 00:00:32,770
But we're going to be taking
a closer look at those SSIDs

12
00:00:32,770 --> 00:00:35,390
and their attributes
in this video.

13
00:00:35,390 --> 00:00:37,450
We'll also be taking a
look at something called

14
00:00:37,450 --> 00:00:42,610
a node SSID, which is sort of
a subset of the prefix SSID,

15
00:00:42,610 --> 00:00:45,110
but we'll see how
that works as well.

16
00:00:45,110 --> 00:00:47,140
We'll also take a
little bit of a look

17
00:00:47,140 --> 00:00:50,360
at what happens in
the case of a failure.

18
00:00:50,360 --> 00:00:52,150
And then we'll jump
in and take a look

19
00:00:52,150 --> 00:00:56,290
at a special use case
of using a prefix

20
00:00:56,290 --> 00:00:59,330
SSID for an anycast address.

21
00:00:59,330 --> 00:01:01,570
So let's go ahead and
jump in and take a look

22
00:01:01,570 --> 00:01:07,020
at the details of each of
these different types of SSIDs.

23
00:01:07,020 --> 00:01:10,590
So let's start off by
talking about the attributes

24
00:01:10,590 --> 00:01:13,200
of the prefix SSIDs.

25
00:01:13,200 --> 00:01:18,990
These represent the shortest
path to a specific destination

26
00:01:18,990 --> 00:01:20,320
prefix.

27
00:01:20,320 --> 00:01:23,880
You could also basically
refer to this as a route

28
00:01:23,880 --> 00:01:25,950
to the destination.

29
00:01:25,950 --> 00:01:30,930
And like a route, it does
fully support equal cost

30
00:01:30,930 --> 00:01:35,160
multipathing just like
our routing table does.

31
00:01:35,160 --> 00:01:37,620
We've already discussed
the fact that this

32
00:01:37,620 --> 00:01:43,500
gets distributed through
your IGP, so OSPF or IS-IS.

33
00:01:43,500 --> 00:01:48,330
It also, of course, has to be
unique within the SR domain,

34
00:01:48,330 --> 00:01:51,180
just like a route to
a destination would.

35
00:01:51,180 --> 00:01:53,100
Now, there is a minor
exception to this

36
00:01:53,100 --> 00:01:56,010
that we're going to talk about
in a couple minutes, which

37
00:01:56,010 --> 00:01:57,090
is anycast.

38
00:01:57,090 --> 00:01:59,430
It's sort of an
exception to this rule.

39
00:01:59,430 --> 00:02:03,060
But for the most part, for the
majority of our destinations,

40
00:02:03,060 --> 00:02:05,430
this will, of course, be unique.

41
00:02:05,430 --> 00:02:09,310
These are allocated from
the Segment Routing Global

42
00:02:09,310 --> 00:02:12,430
Block, which, of
course, is by default

43
00:02:12,430 --> 00:02:19,090
that 16,000 through 23,999.

44
00:02:19,090 --> 00:02:23,740
So this is where those labels
are going to be pulled from.

45
00:02:23,740 --> 00:02:26,350
Now, we say pulled,
but keep in mind,

46
00:02:26,350 --> 00:02:29,470
these are manually configured.

47
00:02:29,470 --> 00:02:32,020
So what that really
means is that you

48
00:02:32,020 --> 00:02:35,230
have to pull from
this range when you're

49
00:02:35,230 --> 00:02:37,630
configuring your prefix SSIDs.

50
00:02:37,630 --> 00:02:40,960
Now, if you remember,
we talked earlier

51
00:02:40,960 --> 00:02:45,800
that these can either
be absolute or index.

52
00:02:45,800 --> 00:02:48,940
So if you choose to do
absolute, again, you

53
00:02:48,940 --> 00:02:52,050
have to pull it
out of this range.

54
00:02:52,050 --> 00:02:54,990
If you configure an
absolute value that's

55
00:02:54,990 --> 00:02:59,790
outside of the SRGB, the router
simply won't assign the label,

56
00:02:59,790 --> 00:03:02,860
and that prefix will
not have a label on it.

57
00:03:02,860 --> 00:03:04,390
That's how it works.

58
00:03:04,390 --> 00:03:07,170
Of course, if you
do index, it's going

59
00:03:07,170 --> 00:03:11,940
to be an index off of the
start point of the SRGB.

60
00:03:11,940 --> 00:03:15,970
So it would start at 16,000
and add the index number.

61
00:03:15,970 --> 00:03:19,890
So that would definitely
be pulled from the SRGB.

62
00:03:19,890 --> 00:03:21,900
You could make the
argument that that

63
00:03:21,900 --> 00:03:24,840
might be one advantage
of doing index

64
00:03:24,840 --> 00:03:27,810
over absolute
because if you ever

65
00:03:27,810 --> 00:03:30,900
needed to change the
range of the SRGB,

66
00:03:30,900 --> 00:03:34,860
the absolute values could
potentially stop working,

67
00:03:34,860 --> 00:03:37,590
but the index values
would just be based off

68
00:03:37,590 --> 00:03:41,070
the new starting
point of the SRGB.

69
00:03:41,070 --> 00:03:44,550
So it could be argued that that
might be an advantage of doing

70
00:03:44,550 --> 00:03:47,440
index over absolute values.

71
00:03:47,440 --> 00:03:51,910
Now, sort of an interesting
one here is the node segment.

72
00:03:51,910 --> 00:03:56,570
The node segment is
a prefix segment,

73
00:03:56,570 --> 00:04:00,700
which means it's actually
one of these types of SSIDs.

74
00:04:00,700 --> 00:04:02,860
What makes it
unique is that it's

75
00:04:02,860 --> 00:04:08,950
associated with a host prefix
that identifies the node.

76
00:04:08,950 --> 00:04:12,820
That makes this work a
bit like a router ID would

77
00:04:12,820 --> 00:04:16,750
in, say, OSPF or BGP.

78
00:04:16,750 --> 00:04:20,740
And to indicate that, there's
a special flag on this

79
00:04:20,740 --> 00:04:25,450
called the N-flag that is
set in that advertisement

80
00:04:25,450 --> 00:04:28,180
to indicate that it's a node.

81
00:04:28,180 --> 00:04:32,800
Now, sort of the interesting
thing here is that, by default,

82
00:04:32,800 --> 00:04:38,590
each prefix SSID
actually is a node SSID.

83
00:04:38,590 --> 00:04:41,620
So essentially,
they're the same thing

84
00:04:41,620 --> 00:04:47,020
unless you configure a prefix
SSID to not be a node SSID.

85
00:04:47,020 --> 00:04:49,180
So hopefully, we
can see here how

86
00:04:49,180 --> 00:04:55,360
the node segment is sort of like
a subset of the prefix segment.

87
00:04:55,360 --> 00:05:00,030
So basically, you could say that
all node segments are prefix

88
00:05:00,030 --> 00:05:03,780
segments but not necessarily
all prefix segments

89
00:05:03,780 --> 00:05:05,530
are node segments.

90
00:05:05,530 --> 00:05:08,400
However, of course,
by default, they are.

91
00:05:08,400 --> 00:05:10,950
But that's sort of the way
to think of it in the fact

92
00:05:10,950 --> 00:05:15,170
that it's a subset
of the prefix SSID.

93
00:05:15,170 --> 00:05:19,310
Our next type of SSID
is the adjacency SSID.

94
00:05:19,310 --> 00:05:22,790
The adjacency SSIDs are
for the local segments,

95
00:05:22,790 --> 00:05:25,610
and they only have
local significance.

96
00:05:25,610 --> 00:05:28,490
These are for directly
connected neighbors.

97
00:05:28,490 --> 00:05:31,880
These do not come
out of the SRGB.

98
00:05:31,880 --> 00:05:34,910
These come out of
the dynamic label

99
00:05:34,910 --> 00:05:41,120
pool, the same as every other
label that MPLS normally uses.

100
00:05:41,120 --> 00:05:47,420
On IOS XR, that
would be 24,000 plus.

101
00:05:47,420 --> 00:05:53,840
On IOS XE, that's 16 plus
by default. So again,

102
00:05:53,840 --> 00:05:57,350
their dynamic label range
is different by default

103
00:05:57,350 --> 00:05:59,030
on these two platforms.

104
00:05:59,030 --> 00:06:01,790
Something else a little
bit interesting about these

105
00:06:01,790 --> 00:06:06,590
is they will be different
after a chassis reload.

106
00:06:06,590 --> 00:06:08,780
Now, if you think
about it, we're

107
00:06:08,780 --> 00:06:11,070
talking about adjacencies here.

108
00:06:11,070 --> 00:06:13,520
And when you reload
a device, it's

109
00:06:13,520 --> 00:06:16,800
going to come up and form
new adjacencies anyway.

110
00:06:16,800 --> 00:06:20,620
So there's no need for
this to be the same.

111
00:06:20,620 --> 00:06:23,640
There's no need to have
label persistence here

112
00:06:23,640 --> 00:06:25,140
between reloads.

113
00:06:25,140 --> 00:06:27,720
So at this point,
it's perfectly fine.

114
00:06:27,720 --> 00:06:30,060
And just to make sure
we make it clear,

115
00:06:30,060 --> 00:06:34,240
that label is assigned
per adjacency.

116
00:06:34,240 --> 00:06:38,790
So each adjacency we have will
have its own adjacency SSID.

117
00:06:38,790 --> 00:06:42,390
But what happens when one of
these adjacencies goes down?

118
00:06:42,390 --> 00:06:46,620
Well, in the event of a failure,
here's what's going to happen.

119
00:06:46,620 --> 00:06:51,150
First, the IGP is
going to free the label

120
00:06:51,150 --> 00:06:53,830
when the adjacency goes down.

121
00:06:53,830 --> 00:06:56,470
So this is fairly
common practice

122
00:06:56,470 --> 00:07:01,200
just like you would declare an
OSPF neighborship or an ISIS

123
00:07:01,200 --> 00:07:04,710
adjacency down if we
lose the interface

124
00:07:04,710 --> 00:07:08,020
or we hit a dead time
or something like that.

125
00:07:08,020 --> 00:07:11,380
Now, here's where things get
a little more interesting.

126
00:07:11,380 --> 00:07:15,150
We have something called the
Label Switching Database,

127
00:07:15,150 --> 00:07:17,040
or the LSD.

128
00:07:17,040 --> 00:07:22,020
And what this does is it
keeps those freed labels,

129
00:07:22,020 --> 00:07:26,130
the ones that got freed up when
this went down, in something

130
00:07:26,130 --> 00:07:29,460
called a zombie label table.

131
00:07:29,460 --> 00:07:35,800
These zombie labels will be kept
in the database for 30 minutes.

132
00:07:35,800 --> 00:07:39,390
And if we don't use
them again, that label

133
00:07:39,390 --> 00:07:43,660
will then get recycled
after it times out.

134
00:07:43,660 --> 00:07:47,110
Well, how do we know if
we're going to use it again?

135
00:07:47,110 --> 00:07:49,500
That's fairly straightforward.

136
00:07:49,500 --> 00:07:53,700
When the LSD gets
that label request

137
00:07:53,700 --> 00:07:59,490
that happens to match a zombie
label, it then revives it.

138
00:07:59,490 --> 00:08:02,250
Just like a zombie, we're
bringing it back to life,

139
00:08:02,250 --> 00:08:04,450
and we start using it again.

140
00:08:04,450 --> 00:08:10,290
So this way if something is
down for 30 minutes or less,

141
00:08:10,290 --> 00:08:14,820
it will get the same label
after that failure is recovered.

142
00:08:14,820 --> 00:08:17,310
If it's longer than
30 minutes, then

143
00:08:17,310 --> 00:08:19,890
we'll simply have to
create new labels when

144
00:08:19,890 --> 00:08:22,150
those adjacencies come back up.

145
00:08:22,150 --> 00:08:24,960
So just as a reminder,
let's talk about how

146
00:08:24,960 --> 00:08:26,860
these segments are used.

147
00:08:26,860 --> 00:08:29,490
Remember that what
happens is these

148
00:08:29,490 --> 00:08:34,049
get combined to create
this traffic engineering

149
00:08:34,049 --> 00:08:37,200
path or source-based routing.

150
00:08:37,200 --> 00:08:42,179
The path is specified
by a list of segments,

151
00:08:42,179 --> 00:08:44,640
of course, implemented
with a label stack

152
00:08:44,640 --> 00:08:48,480
in the data plane that's
put into the packet header.

153
00:08:48,480 --> 00:08:51,660
This entire path
is only going to be

154
00:08:51,660 --> 00:08:54,880
known by the headend router.

155
00:08:54,880 --> 00:08:58,240
This is what's being
considered the source.

156
00:08:58,240 --> 00:09:00,570
And this is the only
device that needs

157
00:09:00,570 --> 00:09:03,400
to be aware of the
path being requested.

158
00:09:03,400 --> 00:09:08,880
The path itself is not
signaled to any other router

159
00:09:08,880 --> 00:09:11,370
simply because it's
just not needed.

160
00:09:11,370 --> 00:09:15,120
The devices in the middle don't
need to know the entire path.

161
00:09:15,120 --> 00:09:17,640
Remember, they do
their label switching

162
00:09:17,640 --> 00:09:19,350
based on the top label.

163
00:09:19,350 --> 00:09:22,620
Once that label has
been used, it's removed.

164
00:09:22,620 --> 00:09:24,960
And then we send it
on to the next device

165
00:09:24,960 --> 00:09:29,010
who then uses the next
segment for its forwarding.

166
00:09:29,010 --> 00:09:32,700
And because we're using
this hop-by-hop paradigm

167
00:09:32,700 --> 00:09:36,460
where we're taking each
label off as we use them,

168
00:09:36,460 --> 00:09:40,800
there is going to be no
per-flow state created

169
00:09:40,800 --> 00:09:44,520
in the core, which really
makes this very scalable

170
00:09:44,520 --> 00:09:47,530
because we're not trying
to maintain states.

171
00:09:47,530 --> 00:09:51,750
So let's wrap up with one
sort of special use case

172
00:09:51,750 --> 00:09:57,220
for our prefix SSID, which
is the anycast prefix SSID.

173
00:09:57,220 --> 00:09:59,520
So let's discuss these
points and then take

174
00:09:59,520 --> 00:10:01,810
a look at what this
actually means.

175
00:10:01,810 --> 00:10:05,970
So first, anycast just
sort of by definition

176
00:10:05,970 --> 00:10:10,770
here is the same
prefix being advertised

177
00:10:10,770 --> 00:10:13,920
by different devices.

178
00:10:13,920 --> 00:10:15,570
Now, there's sort
of a key factor

179
00:10:15,570 --> 00:10:18,480
we have to understand
here to really understand

180
00:10:18,480 --> 00:10:20,250
the concept of anycast.

181
00:10:20,250 --> 00:10:25,380
Since this is multiple devices
advertising the same address,

182
00:10:25,380 --> 00:10:29,280
that means that end
devices would end up

183
00:10:29,280 --> 00:10:34,110
at really any of the devices
with that address expecting

184
00:10:34,110 --> 00:10:36,190
a particular service.

185
00:10:36,190 --> 00:10:42,060
So a key element of anycast is
that all of the devices sharing

186
00:10:42,060 --> 00:10:46,290
this IP address have to be
offering the same services,

187
00:10:46,290 --> 00:10:48,210
whatever that may be.

188
00:10:48,210 --> 00:10:53,140
Common uses here would be things
like DNS servers, web servers,

189
00:10:53,140 --> 00:10:56,850
network load balancers,
email exchanges, things

190
00:10:56,850 --> 00:11:00,630
along those lines, maybe
even time servers, so sort

191
00:11:00,630 --> 00:11:03,630
of generic services
usually, but things

192
00:11:03,630 --> 00:11:06,820
that we want to be able to get
to the closest instance of.

193
00:11:06,820 --> 00:11:08,370
So let's finish up
our points here,

194
00:11:08,370 --> 00:11:10,140
and then we'll diagram
this out so you

195
00:11:10,140 --> 00:11:12,130
can get an idea of what
we're talking about.

196
00:11:12,130 --> 00:11:15,660
So just like any other
prefix, the prefix

197
00:11:15,660 --> 00:11:18,810
that we're going to be
using for the anycast

198
00:11:18,810 --> 00:11:21,060
still gets a prefix SSID.

199
00:11:21,060 --> 00:11:24,910
So this is sort of going to
function exactly the same way.

200
00:11:24,910 --> 00:11:26,760
But you'll see when
we diagram it out

201
00:11:26,760 --> 00:11:28,870
what makes it a
little bit different.

202
00:11:28,870 --> 00:11:30,480
And then of course,
the main idea

203
00:11:30,480 --> 00:11:35,250
here is traffic is going to
be forwarded to the closest

204
00:11:35,250 --> 00:11:39,230
instance of that anycast SSID.

205
00:11:39,230 --> 00:11:44,870
Anycast is often referred
to as "one to closest"

206
00:11:44,870 --> 00:11:47,840
because we're going to be going
from one device on our network

207
00:11:47,840 --> 00:11:53,630
to the closest instance of
this particular anycast SSID.

208
00:11:53,630 --> 00:11:56,900
If any of these
devices were to fail,

209
00:11:56,900 --> 00:12:00,830
the IGP will simply reroute
the traffic to whatever

210
00:12:00,830 --> 00:12:03,560
the next closest device is.

211
00:12:03,560 --> 00:12:06,380
So just to give a quick
example, let's just

212
00:12:06,380 --> 00:12:11,060
say we had a few devices here,
and they have the same address.

213
00:12:11,060 --> 00:12:14,270
These devices are then connected
into the rest of our network.

214
00:12:14,270 --> 00:12:16,920
We'll just put some
routers down here.

215
00:12:16,920 --> 00:12:19,100
So maybe they're
connected like this.

216
00:12:19,100 --> 00:12:22,580
And then, if traffic
comes into, say,

217
00:12:22,580 --> 00:12:26,942
this bottom left router going
to this IP address, what

218
00:12:26,942 --> 00:12:29,150
it's going to do is it's
going to forward the traffic

219
00:12:29,150 --> 00:12:31,760
to the closest path,
again, according

220
00:12:31,760 --> 00:12:34,700
to the IGP, which
would most likely be

221
00:12:34,700 --> 00:12:39,720
this direction assuming all of
these links have the same cost.

222
00:12:39,720 --> 00:12:42,500
So in this case, the
traffic would hit the device

223
00:12:42,500 --> 00:12:43,658
on the left.

224
00:12:43,658 --> 00:12:45,200
On the other hand,
if we were talking

225
00:12:45,200 --> 00:12:47,600
about this router on
the right over here,

226
00:12:47,600 --> 00:12:51,200
it would, of course,
take the path this way

227
00:12:51,200 --> 00:12:53,550
to get to the destination.

228
00:12:53,550 --> 00:12:57,350
So this is the idea
of "one to closest."

229
00:12:57,350 --> 00:13:00,630
We're going to the closest
instance of that address.

230
00:13:00,630 --> 00:13:03,890
And in order for this to work
the same way with segment

231
00:13:03,890 --> 00:13:08,000
routing as it does
with IP, each of these

232
00:13:08,000 --> 00:13:09,550
would have the same label.

233
00:13:09,550 --> 00:13:12,830
So say, for example,
this is 1610.

234
00:13:12,830 --> 00:13:16,850
This one would also be 1610.

235
00:13:16,850 --> 00:13:20,900
So as this is being sent
out, we see two paths

236
00:13:20,900 --> 00:13:23,450
to get to the same destination.

237
00:13:23,450 --> 00:13:26,540
And that would be
your anycast SSID.

238
00:13:26,540 --> 00:13:31,040
Now, just to wrap this up, if
any of these devices or paths

239
00:13:31,040 --> 00:13:36,320
were to fail, that path would,
of course, become unavailable.

240
00:13:36,320 --> 00:13:38,120
And then, all of a
sudden, the traffic

241
00:13:38,120 --> 00:13:42,660
would start going this way, even
though it's a much longer path.

242
00:13:42,660 --> 00:13:45,960
We still have redundancy,
and everybody will still

243
00:13:45,960 --> 00:13:48,280
be able to get to
the same service.

244
00:13:48,280 --> 00:13:52,660
So this is the basic idea
behind how anycast works.

245
00:13:52,660 --> 00:13:56,160
We're just simply
adding a prefix SSID

246
00:13:56,160 --> 00:14:00,670
into the mix with IPv4 anycast.

247
00:14:00,670 --> 00:14:05,110
So in this video, we jumped
in, and we took a closer look

248
00:14:05,110 --> 00:14:07,930
at the different types
of SSIDs that we have

249
00:14:07,930 --> 00:14:10,280
available in segment routing.

250
00:14:10,280 --> 00:14:14,470
So we took a look at the prefix
SSID, it's sort of subtype,

251
00:14:14,470 --> 00:14:16,720
if you will, the node SSID.

252
00:14:16,720 --> 00:14:19,630
Then, of course, we talked
about the adjacency SSID.

253
00:14:19,630 --> 00:14:22,480
We talked about
anycast SSIDs, which

254
00:14:22,480 --> 00:14:26,800
is pretty much just a special
use case of the prefix SSID.

255
00:14:26,800 --> 00:14:29,230
And of course, we also
talked a little bit

256
00:14:29,230 --> 00:14:33,550
about those zombie entries
in our label database

257
00:14:33,550 --> 00:14:38,230
that we can use if the entry
is not more than 30 minutes old

258
00:14:38,230 --> 00:14:40,750
so we can sort of get a
little bit of persistence

259
00:14:40,750 --> 00:14:44,720
with the labels in the event
of a momentary failure.

260
00:14:44,720 --> 00:14:47,650
Now, we've talked a
little bit about failures,

261
00:14:47,650 --> 00:14:50,290
but sometimes, we need a
little bit more protection

262
00:14:50,290 --> 00:14:51,710
from failures.

263
00:14:51,710 --> 00:14:55,000
So next, we're going to take
a look at something called

264
00:14:55,000 --> 00:14:58,960
topology-independent
loop-free alternative, which

265
00:14:58,960 --> 00:15:00,770
we can use to
quickly route around

266
00:15:00,770 --> 00:15:03,240
problems in our topology.

267
00:15:03,240 --> 00:15:05,490
So that's what we're going
to be jumping into next.

268
00:15:05,490 --> 00:15:06,870
I'll see you there.

269
00:15:06,870 --> 00:15:09,140
I hope this has been
informative for you,

270
00:15:09,140 --> 00:15:12,280
and I'd like to thank
you for viewing.

271
00:15:12,280 --> 00:15:16,000