[AUDIO LOGO]
So now that we're starting to get a better idea of how
segment routing operates, it's time
to take a closer look at those segment identifiers or SSIDs
that we've been sort of talking about as we've been going
through the previous sections.
We've already sort of addressed prefix SSIDs a little bit.
We've also mentioned adjacency SSIDs.
But we're going to be taking a closer look at those SSIDs
and their attributes in this video.
We'll also be taking a look at something called
a node SSID, which is sort of a subset of the prefix SSID,
but we'll see how that works as well.
We'll also take a little bit of a look
at what happens in the case of a failure.
And then we'll jump in and take a look
at a special use case of using a prefix
SSID for an anycast address.
So let's go ahead and jump in and take a look
at the details of each of these different types of SSIDs.
So let's start off by talking about the attributes
of the prefix SSIDs.
These represent the shortest path to a specific destination
prefix.
You could also basically refer to this as a route
to the destination.
And like a route, it does fully support equal cost
multipathing just like our routing table does.
We've already discussed the fact that this
gets distributed through your IGP, so OSPF or IS-IS.
It also, of course, has to be unique within the SR domain,
just like a route to a destination would.
Now, there is a minor exception to this
that we're going to talk about in a couple minutes, which
is anycast.
It's sort of an exception to this rule.
But for the most part, for the majority of our destinations,
this will, of course, be unique.
These are allocated from the Segment Routing Global
Block, which, of course, is by default
that 16,000 through 23,999.
So this is where those labels are going to be pulled from.
Now, we say pulled, but keep in mind,
these are manually configured.
So what that really means is that you
have to pull from this range when you're
configuring your prefix SSIDs.
Now, if you remember, we talked earlier
that these can either be absolute or index.
So if you choose to do absolute, again, you
have to pull it out of this range.
If you configure an absolute value that's
outside of the SRGB, the router simply won't assign the label,
and that prefix will not have a label on it.
That's how it works.
Of course, if you do index, it's going
to be an index off of the start point of the SRGB.
So it would start at 16,000 and add the index number.
So that would definitely be pulled from the SRGB.
You could make the argument that that
might be one advantage of doing index
over absolute because if you ever
needed to change the range of the SRGB,
the absolute values could potentially stop working,
but the index values would just be based off
the new starting point of the SRGB.
So it could be argued that that might be an advantage of doing
index over absolute values.
Now, sort of an interesting one here is the node segment.
The node segment is a prefix segment,
which means it's actually one of these types of SSIDs.
What makes it unique is that it's
associated with a host prefix that identifies the node.
That makes this work a bit like a router ID would
in, say, OSPF or BGP.
And to indicate that, there's a special flag on this
called the N-flag that is set in that advertisement
to indicate that it's a node.
Now, sort of the interesting thing here is that, by default,
each prefix SSID actually is a node SSID.
So essentially, they're the same thing
unless you configure a prefix SSID to not be a node SSID.
So hopefully, we can see here how
the node segment is sort of like a subset of the prefix segment.
So basically, you could say that all node segments are prefix
segments but not necessarily all prefix segments
are node segments.
However, of course, by default, they are.
But that's sort of the way to think of it in the fact
that it's a subset of the prefix SSID.
Our next type of SSID is the adjacency SSID.
The adjacency SSIDs are for the local segments,
and they only have local significance.
These are for directly connected neighbors.
These do not come out of the SRGB.
These come out of the dynamic label
pool, the same as every other label that MPLS normally uses.
On IOS XR, that would be 24,000 plus.
On IOS XE, that's 16 plus by default. So again,
their dynamic label range is different by default
on these two platforms.
Something else a little bit interesting about these
is they will be different after a chassis reload.
Now, if you think about it, we're
talking about adjacencies here.
And when you reload a device, it's
going to come up and form new adjacencies anyway.
So there's no need for this to be the same.
There's no need to have label persistence here
between reloads.
So at this point, it's perfectly fine.
And just to make sure we make it clear,
that label is assigned per adjacency.
So each adjacency we have will have its own adjacency SSID.
But what happens when one of these adjacencies goes down?
Well, in the event of a failure, here's what's going to happen.
First, the IGP is going to free the label
when the adjacency goes down.
So this is fairly common practice
just like you would declare an OSPF neighborship or an ISIS
adjacency down if we lose the interface
or we hit a dead time or something like that.
Now, here's where things get a little more interesting.
We have something called the Label Switching Database,
or the LSD.
And what this does is it keeps those freed labels,
the ones that got freed up when this went down, in something
called a zombie label table.
These zombie labels will be kept in the database for 30 minutes.
And if we don't use them again, that label
will then get recycled after it times out.
Well, how do we know if we're going to use it again?
That's fairly straightforward.
When the LSD gets that label request
that happens to match a zombie label, it then revives it.
Just like a zombie, we're bringing it back to life,
and we start using it again.
So this way if something is down for 30 minutes or less,
it will get the same label after that failure is recovered.
If it's longer than 30 minutes, then
we'll simply have to create new labels when
those adjacencies come back up.
So just as a reminder, let's talk about how
these segments are used.
Remember that what happens is these
get combined to create this traffic engineering
path or source-based routing.
The path is specified by a list of segments,
of course, implemented with a label stack
in the data plane that's put into the packet header.
This entire path is only going to be
known by the headend router.
This is what's being considered the source.
And this is the only device that needs
to be aware of the path being requested.
The path itself is not signaled to any other router
simply because it's just not needed.
The devices in the middle don't need to know the entire path.
Remember, they do their label switching
based on the top label.
Once that label has been used, it's removed.
And then we send it on to the next device
who then uses the next segment for its forwarding.
And because we're using this hop-by-hop paradigm
where we're taking each label off as we use them,
there is going to be no per-flow state created
in the core, which really makes this very scalable
because we're not trying to maintain states.
So let's wrap up with one sort of special use case
for our prefix SSID, which is the anycast prefix SSID.
So let's discuss these points and then take
a look at what this actually means.
So first, anycast just sort of by definition
here is the same prefix being advertised
by different devices.
Now, there's sort of a key factor
we have to understand here to really understand
the concept of anycast.
Since this is multiple devices advertising the same address,
that means that end devices would end up
at really any of the devices with that address expecting
a particular service.
So a key element of anycast is that all of the devices sharing
this IP address have to be offering the same services,
whatever that may be.
Common uses here would be things like DNS servers, web servers,
network load balancers, email exchanges, things
along those lines, maybe even time servers, so sort
of generic services usually, but things
that we want to be able to get to the closest instance of.
So let's finish up our points here,
and then we'll diagram this out so you
can get an idea of what we're talking about.
So just like any other prefix, the prefix
that we're going to be using for the anycast
still gets a prefix SSID.
So this is sort of going to function exactly the same way.
But you'll see when we diagram it out
what makes it a little bit different.
And then of course, the main idea
here is traffic is going to be forwarded to the closest
instance of that anycast SSID.
Anycast is often referred to as "one to closest"
because we're going to be going from one device on our network
to the closest instance of this particular anycast SSID.
If any of these devices were to fail,
the IGP will simply reroute the traffic to whatever
the next closest device is.
So just to give a quick example, let's just
say we had a few devices here, and they have the same address.
These devices are then connected into the rest of our network.
We'll just put some routers down here.
So maybe they're connected like this.
And then, if traffic comes into, say,
this bottom left router going to this IP address, what
it's going to do is it's going to forward the traffic
to the closest path, again, according
to the IGP, which would most likely be
this direction assuming all of these links have the same cost.
So in this case, the traffic would hit the device
on the left.
On the other hand, if we were talking
about this router on the right over here,
it would, of course, take the path this way
to get to the destination.
So this is the idea of "one to closest."
We're going to the closest instance of that address.
And in order for this to work the same way with segment
routing as it does with IP, each of these
would have the same label.
So say, for example, this is 1610.
This one would also be 1610.
So as this is being sent out, we see two paths
to get to the same destination.
And that would be your anycast SSID.
Now, just to wrap this up, if any of these devices or paths
were to fail, that path would, of course, become unavailable.
And then, all of a sudden, the traffic
would start going this way, even though it's a much longer path.
We still have redundancy, and everybody will still
be able to get to the same service.
So this is the basic idea behind how anycast works.
We're just simply adding a prefix SSID
into the mix with IPv4 anycast.
So in this video, we jumped in, and we took a closer look
at the different types of SSIDs that we have
available in segment routing.
So we took a look at the prefix SSID, it's sort of subtype,
if you will, the node SSID.
Then, of course, we talked about the adjacency SSID.
We talked about anycast SSIDs, which
is pretty much just a special use case of the prefix SSID.
And of course, we also talked a little bit
about those zombie entries in our label database
that we can use if the entry is not more than 30 minutes old
so we can sort of get a little bit of persistence
with the labels in the event of a momentary failure.
Now, we've talked a little bit about failures,
but sometimes, we need a little bit more protection
from failures.
So next, we're going to take a look at something called
topology-independent loop-free alternative, which
we can use to quickly route around
problems in our topology.
So that's what we're going to be jumping into next.
I'll see you there.
I hope this has been informative for you,
and I'd like to thank you for viewing.