1
00:00:00,000 --> 00:00:03,479
[MUSIC PLAYING]

2
00:00:03,479 --> 00:00:12,440

3
00:00:12,440 --> 00:00:16,940
Moving right along, we're
now on Trouble Ticket 3,

4
00:00:16,940 --> 00:00:21,740
as we can see here, this is
still on MPLS Topology 1.

5
00:00:21,740 --> 00:00:24,050
So that's going
to be our diagram,

6
00:00:24,050 --> 00:00:27,980
and our core protocol
is still IS-IS.

7
00:00:27,980 --> 00:00:28,860
This time.

8
00:00:28,860 --> 00:00:32,700
However our ticket is
a little bit different.

9
00:00:32,700 --> 00:00:36,830
Now traffic from
outer 8 to router 1

10
00:00:36,830 --> 00:00:39,020
is not being label-switched.

11
00:00:39,020 --> 00:00:42,440
So slightly different
problem, same symptom.

12
00:00:42,440 --> 00:00:44,690
Let's go ahead and jump
into the command line.

13
00:00:44,690 --> 00:00:49,100
As always, we'll start on
router 8, verifying the ticket,

14
00:00:49,100 --> 00:00:53,040
and then we'll do our
troubleshooting from there.

15
00:00:53,040 --> 00:00:56,570
So we'll start, once again,
with doing a trace to 10.1.1.1.

16
00:00:56,570 --> 00:00:59,580
We'll source it from our
loopback 0 interface.

17
00:00:59,580 --> 00:01:02,910
So as we can see, once
again, the ticket is correct.

18
00:01:02,910 --> 00:01:05,630
We are getting no
labels when we're going

19
00:01:05,630 --> 00:01:08,070
towards router 1's loopback.

20
00:01:08,070 --> 00:01:10,580
So let's go to our
first hop router.

21
00:01:10,580 --> 00:01:14,120
In this direction, that's
going to be router 5.

22
00:01:14,120 --> 00:01:20,060
On router 5, let's do a
show, segment-routing, MPLS,

23
00:01:20,060 --> 00:01:24,890
connected-prefix-sid-map
for IPv4.

24
00:01:24,890 --> 00:01:28,460
What we're seeing on
this output is that, yes,

25
00:01:28,460 --> 00:01:33,440
we have our own prefix here,
and we're learning prefixes

26
00:01:33,440 --> 00:01:38,990
for routers 2, 3, 4 and 5
with their appropriate SIDs.

27
00:01:38,990 --> 00:01:43,610
However, we don't have
anything for router 1.

28
00:01:43,610 --> 00:01:45,590
Since we don't have
a label for it,

29
00:01:45,590 --> 00:01:48,770
if we do a show MPLS
forwarding table,

30
00:01:48,770 --> 00:01:50,270
we can see that
we're not even going

31
00:01:50,270 --> 00:01:52,890
to try to impose a
label towards router 1,

32
00:01:52,890 --> 00:01:55,120
we'll just do
standard IP routing,

33
00:01:55,120 --> 00:01:58,230
which is exactly what
we saw in our trace.

34
00:01:58,230 --> 00:02:01,200
So let's just go ahead
and go over to router 1

35
00:02:01,200 --> 00:02:03,860
and see if we can figure
out what's going on.

36
00:02:03,860 --> 00:02:08,340
On router 1 let's try
a show isis segment

37
00:02:08,340 --> 00:02:11,530
routing label table.

38
00:02:11,530 --> 00:02:14,790
Now here's what's interesting
about this output.

39
00:02:14,790 --> 00:02:18,240
First, it's not
blank, which really

40
00:02:18,240 --> 00:02:21,960
doesn't lead us to believe that
segment routing is disabled

41
00:02:21,960 --> 00:02:23,880
on this router.

42
00:02:23,880 --> 00:02:26,910
Remember, we've seen
this in previous tickets.

43
00:02:26,910 --> 00:02:31,420
This is usually empty If
MPLS is not enabled at all.

44
00:02:31,420 --> 00:02:35,460
So it seems like something else
is going on here on router 1.

45
00:02:35,460 --> 00:02:38,490
So given that
information, Let's try

46
00:02:38,490 --> 00:02:41,770
a show MPLS label table detail.

47
00:02:41,770 --> 00:02:45,250
So what we see here is
actually interesting.

48
00:02:45,250 --> 00:02:48,720
We see a label here of 15,000.

49
00:02:48,720 --> 00:02:52,890
But notice that label block
is the segment routing

50
00:02:52,890 --> 00:02:54,480
local block.

51
00:02:54,480 --> 00:02:56,550
That's not the global block.

52
00:02:56,550 --> 00:02:59,580
And, of course, it's not
starting at the proper number,

53
00:02:59,580 --> 00:03:04,080
it's starting at 15,000,
and the size is 1,000.

54
00:03:04,080 --> 00:03:06,160
If we look down
here at the bottom,

55
00:03:06,160 --> 00:03:13,380
however, notice that label
50,000 is listed as the sRGB.

56
00:03:13,380 --> 00:03:17,700
So it looks like somebody
has changed the default sRGB.

57
00:03:17,700 --> 00:03:21,940
Now that in and of itself is
not necessarily a problem.

58
00:03:21,940 --> 00:03:24,330
So let's take a
further look as to what

59
00:03:24,330 --> 00:03:26,220
else might be causing this.

60
00:03:26,220 --> 00:03:29,400
Let's see what our loopback
is actually set for.

61
00:03:29,400 --> 00:03:33,210
Let's do a show
run, router ISIS.

62
00:03:33,210 --> 00:03:35,760
So here we have an
interesting problem.

63
00:03:35,760 --> 00:03:38,460
If we look at our
loopback 0 interface,

64
00:03:38,460 --> 00:03:40,770
we see that the
prefix SID is set

65
00:03:40,770 --> 00:03:44,160
to an absolute value of 16,001.

66
00:03:44,160 --> 00:03:46,860
Now the problem with
this, is we just

67
00:03:46,860 --> 00:03:51,960
saw that 16,001 is
not part of the sRGB.

68
00:03:51,960 --> 00:03:57,810
You cannot have an absolute
value set to a value outside

69
00:03:57,810 --> 00:03:59,550
of the sRGB.

70
00:03:59,550 --> 00:04:03,600
We have seen numerous times
through several skills

71
00:04:03,600 --> 00:04:07,530
that on a lot of devices, it
doesn't understand that it

72
00:04:07,530 --> 00:04:09,520
was set to an absolute value.

73
00:04:09,520 --> 00:04:12,690
What happens is we all
exchange our sRGBs,

74
00:04:12,690 --> 00:04:18,700
and then each of the prefix SIDs
is really carried as an index.

75
00:04:18,700 --> 00:04:21,120
So there's no way this can work.

76
00:04:21,120 --> 00:04:27,870
There's no way an index can be
applied to 16,001, if that's

77
00:04:27,870 --> 00:04:30,060
not part of the sRGB.

78
00:04:30,060 --> 00:04:35,550
So again, the absolute
SID cannot fall outside

79
00:04:35,550 --> 00:04:37,500
of the sRGB.

80
00:04:37,500 --> 00:04:39,980
Now what that means,
is there's a couple

81
00:04:39,980 --> 00:04:41,640
of ways we can fix this.

82
00:04:41,640 --> 00:04:45,390
First, we could change
this to an index value

83
00:04:45,390 --> 00:04:47,760
instead of an absolute value.

84
00:04:47,760 --> 00:04:50,310
We could change
the absolute value

85
00:04:50,310 --> 00:04:53,700
to be something inside
of the sRGB, that

86
00:04:53,700 --> 00:04:55,530
would be valid as well.

87
00:04:55,530 --> 00:05:00,540
Or we could change the sRGB
back to the default values.

88
00:05:00,540 --> 00:05:03,360
Any of those
solutions should work.

89
00:05:03,360 --> 00:05:05,850
Now an interesting
thing here is.

90
00:05:05,850 --> 00:05:07,590
When we're
troubleshooting, I always

91
00:05:07,590 --> 00:05:10,860
encourage people to
look at log files

92
00:05:10,860 --> 00:05:12,870
while they're troubleshooting.

93
00:05:12,870 --> 00:05:15,660
I often don't as we're going
through the troubleshooting

94
00:05:15,660 --> 00:05:19,960
tickets, because sometimes
the answer's just right there,

95
00:05:19,960 --> 00:05:21,870
and then there's
nothing to troubleshoot.

96
00:05:21,870 --> 00:05:23,850
This is actually
an example of where

97
00:05:23,850 --> 00:05:25,390
that would have been the case.

98
00:05:25,390 --> 00:05:27,810
So why don't we go ahead
and look at that log file

99
00:05:27,810 --> 00:05:31,910
before we fix this, so you can
see what I'm talking about.

100
00:05:31,910 --> 00:05:34,780
So let's do a show
log, and we'll

101
00:05:34,780 --> 00:05:38,290
say to include prefix SID.

102
00:05:38,290 --> 00:05:41,860
Notice we got this
log message telling us

103
00:05:41,860 --> 00:05:46,120
that the absolute prefix
SID must be greater than,

104
00:05:46,120 --> 00:05:49,240
or equal to the sRGB start.

105
00:05:49,240 --> 00:05:51,460
Which again, is really
just another way

106
00:05:51,460 --> 00:05:55,570
of saying that it has
to be within the sRGB,

107
00:05:55,570 --> 00:05:59,180
so that it can be referenced
as an index number.

108
00:05:59,180 --> 00:06:02,680
So all of that said,
we do need to fix this.

109
00:06:02,680 --> 00:06:07,420
Probably the best way to fix
it, is just to set the sRGB back

110
00:06:07,420 --> 00:06:08,920
to the default value.

111
00:06:08,920 --> 00:06:10,930
There's really not a
good reason to change

112
00:06:10,930 --> 00:06:13,340
that in most environments.

113
00:06:13,340 --> 00:06:17,650
So if we were to do a show
run, include global block,

114
00:06:17,650 --> 00:06:21,160
we can see that the global block
has been manually configured

115
00:06:21,160 --> 00:06:24,340
to be 50,000 to 100,000.

116
00:06:24,340 --> 00:06:26,750
So we'll simply
just take that out.

117
00:06:26,750 --> 00:06:31,310
So we'll say no segment
routing, global block,

118
00:06:31,310 --> 00:06:34,190
50,000 to 100,000.

119
00:06:34,190 --> 00:06:36,530
We'll commit that change.

120
00:06:36,530 --> 00:06:38,420
We'll exit configuration.

121
00:06:38,420 --> 00:06:41,130
Let's look at our
label table again.

122
00:06:41,130 --> 00:06:45,050
We see that now 16,001 is
being assigned to our loopback

123
00:06:45,050 --> 00:06:47,390
interface as it should be.

124
00:06:47,390 --> 00:06:51,630
If we look at the MPLS
label table detail again,

125
00:06:51,630 --> 00:06:57,020
we see that the sRGB is back to
16,000, with a size of 8,000,

126
00:06:57,020 --> 00:06:59,580
so it's back to
the default value.

127
00:06:59,580 --> 00:07:02,670
Let's go back over to router 5.

128
00:07:02,670 --> 00:07:05,460
If we look at our segment
routing MPLS connected

129
00:07:05,460 --> 00:07:08,580
prefix SID map
for IPv4 again, we

130
00:07:08,580 --> 00:07:11,970
see that now we have
the entry for router 1.

131
00:07:11,970 --> 00:07:15,000
And, of course, that also means
that if we look at our MPLS

132
00:07:15,000 --> 00:07:17,550
forwarding table,
we can see that we

133
00:07:17,550 --> 00:07:21,930
have an outgoing label of
16,001 as we're sending

134
00:07:21,930 --> 00:07:24,810
this both to routers 3 and 4.

135
00:07:24,810 --> 00:07:27,520
So this should
solve the problem.

136
00:07:27,520 --> 00:07:31,080
Let's go back and
verify that on router 8.

137
00:07:31,080 --> 00:07:34,530
Remember, we always want to
verify the original ticket,

138
00:07:34,530 --> 00:07:37,450
even though we think we might
have solved the problem.

139
00:07:37,450 --> 00:07:40,030
Remember, there could
still be other issues.

140
00:07:40,030 --> 00:07:42,660
So we always want to make sure
that the original problem is

141
00:07:42,660 --> 00:07:43,560
solved.

142
00:07:43,560 --> 00:07:47,130
So we see that it solved
at least towards router 4,

143
00:07:47,130 --> 00:07:50,070
because again, we see that
we're now doing label switching,

144
00:07:50,070 --> 00:07:53,430
using the prefix SID of 16,001.

145
00:07:53,430 --> 00:07:56,370
But, once again, this
trace didn't exactly

146
00:07:56,370 --> 00:07:59,310
show us our multipathing,
so let's try it again

147
00:07:59,310 --> 00:08:02,410
and see if we can see the
path through router 3.

148
00:08:02,410 --> 00:08:05,380
So this time trace is being
a little bit stubborn,

149
00:08:05,380 --> 00:08:08,080
it's not showing us the
path through router 3.

150
00:08:08,080 --> 00:08:12,160
However, it is working,
we did see that the labels

151
00:08:12,160 --> 00:08:13,340
are coming through.

152
00:08:13,340 --> 00:08:16,540
So I have fairly high confidence
that the path through router

153
00:08:16,540 --> 00:08:19,480
would also be doing
label switching.

154
00:08:19,480 --> 00:08:20,980
I don't think we
need to keep trying

155
00:08:20,980 --> 00:08:22,940
this to prove that point.

156
00:08:22,940 --> 00:08:26,320
I would still consider this
to be a solution for Trouble

157
00:08:26,320 --> 00:08:28,340
Ticket 3.

158
00:08:28,340 --> 00:08:31,070
So in this ticket,
we saw an example

159
00:08:31,070 --> 00:08:35,419
of a router that had
configured manually the sRGB

160
00:08:35,419 --> 00:08:38,220
to be a non-default range.

161
00:08:38,220 --> 00:08:40,950
Now that's not
generally the problem,

162
00:08:40,950 --> 00:08:43,580
the problem is that
same device was also

163
00:08:43,580 --> 00:08:46,790
using an absolute
prefix SID that was then

164
00:08:46,790 --> 00:08:50,270
outside the range of the sRGB.

165
00:08:50,270 --> 00:08:54,680
And that's a problem, because
most other devices all

166
00:08:54,680 --> 00:08:57,450
reference this as
an index number.

167
00:08:57,450 --> 00:09:00,860
So going off the
starting sRGB range,

168
00:09:00,860 --> 00:09:03,890
it then adds the index
number to figure out

169
00:09:03,890 --> 00:09:05,910
what the prefix label is.

170
00:09:05,910 --> 00:09:11,210
So having that number manually
configured outside of the sRGB

171
00:09:11,210 --> 00:09:13,680
just simply can't be permitted.

172
00:09:13,680 --> 00:09:17,010
Now we also saw that it had
generated a log message.

173
00:09:17,010 --> 00:09:19,190
And if we had looked
at that first,

174
00:09:19,190 --> 00:09:20,900
we probably would
have solved the ticket

175
00:09:20,900 --> 00:09:22,500
maybe a little bit faster.

176
00:09:22,500 --> 00:09:25,190
But we got there either
way, and now our traffic

177
00:09:25,190 --> 00:09:28,830
is working as it should,
going through the environment.

178
00:09:28,830 --> 00:09:31,050
I hope this has been
informative for you,

179
00:09:31,050 --> 00:09:34,190
and I'd like to thank
you for viewing.

180
00:09:34,190 --> 00:09:38,000