1
00:00:00,000 --> 00:00:02,976
[AUDIO LOGO]

2
00:00:02,976 --> 00:00:12,410

3
00:00:12,410 --> 00:00:15,920
Next up, we're moving
on to Trouble Ticket 4.

4
00:00:15,920 --> 00:00:19,750
To this ticket, we're still
going to be on MPLS Topology 1.

5
00:00:19,750 --> 00:00:24,500
However, notice that this
time our core protocol

6
00:00:24,500 --> 00:00:27,470
has switched to OSPF.

7
00:00:27,470 --> 00:00:32,119
Our ticket, however, may look
just a little bit familiar.

8
00:00:32,119 --> 00:00:34,880
Here we have Router
6 is not doing

9
00:00:34,880 --> 00:00:38,960
label switching to 10.5.5.5.

10
00:00:38,960 --> 00:00:42,170
So once again, we're back
to looking at Router 6.

11
00:00:42,170 --> 00:00:45,500
Going to Router 5's loopback,
we've seen this before.

12
00:00:45,500 --> 00:00:48,350
But of course, it's a
different issue this time,

13
00:00:48,350 --> 00:00:51,450
and we have a different
core protocol this time.

14
00:00:51,450 --> 00:00:55,280
So as per usual, let's
jump in, verify the ticket,

15
00:00:55,280 --> 00:00:57,030
make sure that it's
actually broken,

16
00:00:57,030 --> 00:00:59,530
and then of course, we'll start
our troubleshooting process.

17
00:00:59,530 --> 00:01:02,040

18
00:01:02,040 --> 00:01:04,250
So we'll start with our trace.

19
00:01:04,250 --> 00:01:08,640
Again to Router 5's loopback,
sourcing it from our loopback.

20
00:01:08,640 --> 00:01:12,420
So as we can see here on the
trace, the ticket is correct.

21
00:01:12,420 --> 00:01:14,520
We are not doing
label switching.

22
00:01:14,520 --> 00:01:18,170
So let's again go to our
first hop router, Router 1,

23
00:01:18,170 --> 00:01:21,890
and see if it has any
information about Router 5.

24
00:01:21,890 --> 00:01:27,830
So on Router 1, let's do a
show OSPF database opaque-area

25
00:01:27,830 --> 00:01:31,160
for extended prefixes,
and let's just

26
00:01:31,160 --> 00:01:35,720
include the 10.5.5.5 since we
know what we're looking for.

27
00:01:35,720 --> 00:01:38,870
What we see here is
we have no entry.

28
00:01:38,870 --> 00:01:41,720
Now in this particular
case, if you've never

29
00:01:41,720 --> 00:01:44,810
done this command before,
maybe you're not confident

30
00:01:44,810 --> 00:01:46,560
that the filter worked.

31
00:01:46,560 --> 00:01:48,020
So let's try it
for something else

32
00:01:48,020 --> 00:01:50,190
that we suspect is
probably working.

33
00:01:50,190 --> 00:01:53,180
Let's try for example,
Router 3's loopback,

34
00:01:53,180 --> 00:01:55,800
and we see here we
have an entry for it.

35
00:01:55,800 --> 00:01:58,230
So that is in our database.

36
00:01:58,230 --> 00:02:02,010
So the fact that Router 5 is
not is a pretty good indicator

37
00:02:02,010 --> 00:02:03,700
that we have a problem.

38
00:02:03,700 --> 00:02:08,070
Let's go over and see if Router
3 has a label for Router 5.

39
00:02:08,070 --> 00:02:11,730
So we'll simply do the exact
same command on router.

40
00:02:11,730 --> 00:02:14,970
We can see it doesn't
have an entry either.

41
00:02:14,970 --> 00:02:17,830
Let's see if it has an
adjacency SID for it.

42
00:02:17,830 --> 00:02:24,600
So let's do "show OSPF segment
routing adjacency-sids,"

43
00:02:24,600 --> 00:02:30,330
and we see here that we actually
do have an adjacency SID 24,008

44
00:02:30,330 --> 00:02:35,890
for neighbor 10.5.5.5 out our
Gigabit 0/0/0/0 interface,

45
00:02:35,890 --> 00:02:37,960
which looks correct.

46
00:02:37,960 --> 00:02:41,160
So let's verify the
OSPF neighborship.

47
00:02:41,160 --> 00:02:44,430
We'll do a show OSPF
neighbor detail.

48
00:02:44,430 --> 00:02:47,340
So we see here we're
looking at Neighbor 5.

49
00:02:47,340 --> 00:02:49,770
We see that the state is full.

50
00:02:49,770 --> 00:02:52,950
And again, we see down here that
the adjacency SIDs are being

51
00:02:52,950 --> 00:02:54,790
exchanged, which we just saw.

52
00:02:54,790 --> 00:02:57,390
But overall, this
neighborship looks

53
00:02:57,390 --> 00:03:00,850
perfectly fine from
Router 3's perspective.

54
00:03:00,850 --> 00:03:03,780
So let's go ahead and
jump over to Router 5,

55
00:03:03,780 --> 00:03:07,170
see if we configure what's
going on over there.

56
00:03:07,170 --> 00:03:11,300
So let's do a show IP
OSPF database opaque-area

57
00:03:11,300 --> 00:03:14,960
type extended prefix
self-originated.

58
00:03:14,960 --> 00:03:16,820
We'll look at the
database entries

59
00:03:16,820 --> 00:03:19,430
that Router 5
itself is creating.

60
00:03:19,430 --> 00:03:21,380
This is just a way of
filtering the output

61
00:03:21,380 --> 00:03:22,910
to make it a little
more relevant.

62
00:03:22,910 --> 00:03:27,770
And we see here that Router
5 is not generating anything.

63
00:03:27,770 --> 00:03:30,000
Well, does it have any entries?

64
00:03:30,000 --> 00:03:32,120
Let's take the
self-originated off,

65
00:03:32,120 --> 00:03:36,680
and we see that we are, in fact,
getting entries type-10 Opaque

66
00:03:36,680 --> 00:03:39,560
LSAs from other devices.

67
00:03:39,560 --> 00:03:43,880
Just as an example, here's
advertising Router 1 telling us

68
00:03:43,880 --> 00:03:46,370
about its prefix SID.

69
00:03:46,370 --> 00:03:48,980
So we are getting
the information.

70
00:03:48,980 --> 00:03:51,410
We're just not generating any.

71
00:03:51,410 --> 00:03:54,320
So let's see if Router
5 is even configured

72
00:03:54,320 --> 00:03:56,600
to generate a prefix SID.

73
00:03:56,600 --> 00:03:59,510
Let's just do show
run, and we'll

74
00:03:59,510 --> 00:04:02,400
look for the section segment.

75
00:04:02,400 --> 00:04:06,380
So what we see here is
under segment-routing MPLS

76
00:04:06,380 --> 00:04:08,910
in the global
config, it actually

77
00:04:08,910 --> 00:04:13,950
is configured to generate a
prefix SID for its loopback.

78
00:04:13,950 --> 00:04:17,430
It's configured to
generate 16,005.

79
00:04:17,430 --> 00:04:20,050
But we can see that
it's not doing that.

80
00:04:20,050 --> 00:04:25,620
So since it's set to generate
an absolute value of 16,005.

81
00:04:25,620 --> 00:04:28,740
Let's make sure that's
within our SRGB.

82
00:04:28,740 --> 00:04:32,970
So let's do a show
MPLS label range,

83
00:04:32,970 --> 00:04:40,740
and we see that the SRGB is,
in fact, set to 16,000/23,999.

84
00:04:40,740 --> 00:04:43,980
So this is the
default SRGB range.

85
00:04:43,980 --> 00:04:46,570
Our absolute value
is within that range.

86
00:04:46,570 --> 00:04:49,150
So that's not the problem.

87
00:04:49,150 --> 00:04:51,660
So maybe this is an OSPF issue.

88
00:04:51,660 --> 00:04:54,750
Let's do a show
run section OSPF.

89
00:04:54,750 --> 00:04:58,410
Now all of these top
entries are the OSPF entries

90
00:04:58,410 --> 00:05:00,100
under the interfaces.

91
00:05:00,100 --> 00:05:02,220
So if we look down here
at the global process,

92
00:05:02,220 --> 00:05:05,280
we see that all it's configured
for is the router ID.

93
00:05:05,280 --> 00:05:09,510
This is not enabled
for segment routing.

94
00:05:09,510 --> 00:05:11,810
Now of course, what's
interesting about this,

95
00:05:11,810 --> 00:05:15,410
and we saw this in some
previous tickets with ISIS

96
00:05:15,410 --> 00:05:19,700
as well, not having
the protocol enabled

97
00:05:19,700 --> 00:05:22,790
doesn't necessarily stop
the protocol from learning

98
00:05:22,790 --> 00:05:23,940
information.

99
00:05:23,940 --> 00:05:27,650
So this device has learned
things like prefix SIDs

100
00:05:27,650 --> 00:05:29,060
from other routers.

101
00:05:29,060 --> 00:05:33,770
It's just not putting its
own information into OSPF.

102
00:05:33,770 --> 00:05:35,540
So this is clearly--

103
00:05:35,540 --> 00:05:36,960
probably, our issue.

104
00:05:36,960 --> 00:05:41,170
Let's go ahead and fix this and
see if it solves the problem.

105
00:05:41,170 --> 00:05:46,140
So let's go into configuration
mode in the Router OSPF 1,

106
00:05:46,140 --> 00:05:49,770
and we'll turn on
segment routing for MPLS.

107
00:05:49,770 --> 00:05:52,180
Let's exit configuration.

108
00:05:52,180 --> 00:05:54,390
And let's do our verification.

109
00:05:54,390 --> 00:05:58,290
First, let's do our "show
ip OSPF database opaque-area

110
00:05:58,290 --> 00:06:02,040
type extended prefix
self-originated," heck

111
00:06:02,040 --> 00:06:04,270
of a command.

112
00:06:04,270 --> 00:06:06,360
And we see here that
we are now generating

113
00:06:06,360 --> 00:06:12,790
the type-10 Opaque LSA, Opaque
type-7 for the extended prefix.

114
00:06:12,790 --> 00:06:16,070
We see that it is for
our loopback interface,

115
00:06:16,070 --> 00:06:19,900
and it's advertising
an index SID 5.

116
00:06:19,900 --> 00:06:22,460
So this looks like it's correct.

117
00:06:22,460 --> 00:06:24,010
Let's work our way
backwards again,

118
00:06:24,010 --> 00:06:26,260
make sure everything's OK.

119
00:06:26,260 --> 00:06:30,760
If we go back to router and see
if it has the extended prefix,

120
00:06:30,760 --> 00:06:36,370
we see that now it does have
an entry for the 10.5.5.5/32.

121
00:06:36,370 --> 00:06:42,050
Let's check Router
1, Router 1 also

122
00:06:42,050 --> 00:06:44,420
has that entry for Router 5 now.

123
00:06:44,420 --> 00:06:48,090
So let's go back and
verify our original ticket.

124
00:06:48,090 --> 00:06:51,780
So back on Router 6,
we'll do our trace again.

125
00:06:51,780 --> 00:06:54,140
So here we see that
it is working now.

126
00:06:54,140 --> 00:06:56,900
Of course, our
focus being Hop 2,

127
00:06:56,900 --> 00:06:59,810
we see not only are we
doing our multi-pathing,

128
00:06:59,810 --> 00:07:03,230
but we're using
our Label 16,005,

129
00:07:03,230 --> 00:07:05,060
which was the original ticket.

130
00:07:05,060 --> 00:07:10,040
We were, of course, not doing
segment routing/MPLS label

131
00:07:10,040 --> 00:07:10,830
switching.

132
00:07:10,830 --> 00:07:15,910
So I would consider this
to be ticket-4 fixed.

133
00:07:15,910 --> 00:07:19,800
So in this ticket, we saw
an example of a router that

134
00:07:19,800 --> 00:07:23,100
was running OSPF that
had segment routing

135
00:07:23,100 --> 00:07:25,860
enabled globally
but did not have it

136
00:07:25,860 --> 00:07:28,510
enabled under the OSPF process.

137
00:07:28,510 --> 00:07:30,960
The interesting behavior,
of course, that we see

138
00:07:30,960 --> 00:07:34,410
is that OSPF was still
receiving the information.

139
00:07:34,410 --> 00:07:37,890
Router 5 still had
information about its peers

140
00:07:37,890 --> 00:07:40,710
and other devices prefixed SIDs.

141
00:07:40,710 --> 00:07:44,760
It just wasn't putting
its own prefix into OSPF,

142
00:07:44,760 --> 00:07:47,460
even though it was
configured to generate one

143
00:07:47,460 --> 00:07:49,890
under the global configuration.

144
00:07:49,890 --> 00:07:53,640
Once we fixed that, it
started putting its prefix SID

145
00:07:53,640 --> 00:07:55,260
into OSPF.

146
00:07:55,260 --> 00:07:58,980
Everybody else then learned it,
and of course, everybody else

147
00:07:58,980 --> 00:08:02,800
started using it, and
that solved the problem.

148
00:08:02,800 --> 00:08:04,950
I hope this has been
informative for you,

149
00:08:04,950 --> 00:08:08,030
and I'd like to thank
you for viewing.

150
00:08:08,030 --> 00:08:11,000