[MUSIC PLAYING]
Moving right along, we're now on Trouble Ticket 3,
as we can see here, this is still on MPLS Topology 1.
So that's going to be our diagram,
and our core protocol is still IS-IS.
This time.
However our ticket is a little bit different.
Now traffic from outer 8 to router 1
is not being label-switched.
So slightly different problem, same symptom.
Let's go ahead and jump into the command line.
As always, we'll start on router 8, verifying the ticket,
and then we'll do our troubleshooting from there.
So we'll start, once again, with doing a trace to 10.1.1.1.
We'll source it from our loopback 0 interface.
So as we can see, once again, the ticket is correct.
We are getting no labels when we're going
towards router 1's loopback.
So let's go to our first hop router.
In this direction, that's going to be router 5.
On router 5, let's do a show, segment-routing, MPLS,
connected-prefix-sid-map for IPv4.
What we're seeing on this output is that, yes,
we have our own prefix here, and we're learning prefixes
for routers 2, 3, 4 and 5 with their appropriate SIDs.
However, we don't have anything for router 1.
Since we don't have a label for it,
if we do a show MPLS forwarding table,
we can see that we're not even going
to try to impose a label towards router 1,
we'll just do standard IP routing,
which is exactly what we saw in our trace.
So let's just go ahead and go over to router 1
and see if we can figure out what's going on.
On router 1 let's try a show isis segment
routing label table.
Now here's what's interesting about this output.
First, it's not blank, which really
doesn't lead us to believe that segment routing is disabled
on this router.
Remember, we've seen this in previous tickets.
This is usually empty If MPLS is not enabled at all.
So it seems like something else is going on here on router 1.
So given that information, Let's try
a show MPLS label table detail.
So what we see here is actually interesting.
We see a label here of 15,000.
But notice that label block is the segment routing
local block.
That's not the global block.
And, of course, it's not starting at the proper number,
it's starting at 15,000, and the size is 1,000.
If we look down here at the bottom,
however, notice that label 50,000 is listed as the sRGB.
So it looks like somebody has changed the default sRGB.
Now that in and of itself is not necessarily a problem.
So let's take a further look as to what
else might be causing this.
Let's see what our loopback is actually set for.
Let's do a show run, router ISIS.
So here we have an interesting problem.
If we look at our loopback 0 interface,
we see that the prefix SID is set
to an absolute value of 16,001.
Now the problem with this, is we just
saw that 16,001 is not part of the sRGB.
You cannot have an absolute value set to a value outside
of the sRGB.
We have seen numerous times through several skills
that on a lot of devices, it doesn't understand that it
was set to an absolute value.
What happens is we all exchange our sRGBs,
and then each of the prefix SIDs is really carried as an index.
So there's no way this can work.
There's no way an index can be applied to 16,001, if that's
not part of the sRGB.
So again, the absolute SID cannot fall outside
of the sRGB.
Now what that means, is there's a couple
of ways we can fix this.
First, we could change this to an index value
instead of an absolute value.
We could change the absolute value
to be something inside of the sRGB, that
would be valid as well.
Or we could change the sRGB back to the default values.
Any of those solutions should work.
Now an interesting thing here is.
When we're troubleshooting, I always
encourage people to look at log files
while they're troubleshooting.
I often don't as we're going through the troubleshooting
tickets, because sometimes the answer's just right there,
and then there's nothing to troubleshoot.
This is actually an example of where
that would have been the case.
So why don't we go ahead and look at that log file
before we fix this, so you can see what I'm talking about.
So let's do a show log, and we'll
say to include prefix SID.
Notice we got this log message telling us
that the absolute prefix SID must be greater than,
or equal to the sRGB start.
Which again, is really just another way
of saying that it has to be within the sRGB,
so that it can be referenced as an index number.
So all of that said, we do need to fix this.
Probably the best way to fix it, is just to set the sRGB back
to the default value.
There's really not a good reason to change
that in most environments.
So if we were to do a show run, include global block,
we can see that the global block has been manually configured
to be 50,000 to 100,000.
So we'll simply just take that out.
So we'll say no segment routing, global block,
50,000 to 100,000.
We'll commit that change.
We'll exit configuration.
Let's look at our label table again.
We see that now 16,001 is being assigned to our loopback
interface as it should be.
If we look at the MPLS label table detail again,
we see that the sRGB is back to 16,000, with a size of 8,000,
so it's back to the default value.
Let's go back over to router 5.
If we look at our segment routing MPLS connected
prefix SID map for IPv4 again, we
see that now we have the entry for router 1.
And, of course, that also means that if we look at our MPLS
forwarding table, we can see that we
have an outgoing label of 16,001 as we're sending
this both to routers 3 and 4.
So this should solve the problem.
Let's go back and verify that on router 8.
Remember, we always want to verify the original ticket,
even though we think we might have solved the problem.
Remember, there could still be other issues.
So we always want to make sure that the original problem is
solved.
So we see that it solved at least towards router 4,
because again, we see that we're now doing label switching,
using the prefix SID of 16,001.
But, once again, this trace didn't exactly
show us our multipathing, so let's try it again
and see if we can see the path through router 3.
So this time trace is being a little bit stubborn,
it's not showing us the path through router 3.
However, it is working, we did see that the labels
are coming through.
So I have fairly high confidence that the path through router
would also be doing label switching.
I don't think we need to keep trying
this to prove that point.
I would still consider this to be a solution for Trouble
Ticket 3.
So in this ticket, we saw an example
of a router that had configured manually the sRGB
to be a non-default range.
Now that's not generally the problem,
the problem is that same device was also
using an absolute prefix SID that was then
outside the range of the sRGB.
And that's a problem, because most other devices all
reference this as an index number.
So going off the starting sRGB range,
it then adds the index number to figure out
what the prefix label is.
So having that number manually configured outside of the sRGB
just simply can't be permitted.
Now we also saw that it had generated a log message.
And if we had looked at that first,
we probably would have solved the ticket
maybe a little bit faster.
But we got there either way, and now our traffic
is working as it should, going through the environment.
I hope this has been informative for you,
and I'd like to thank you for viewing.