1
00:00:00,000 --> 00:00:03,920
[AUDIO LOGO]

2
00:00:03,920 --> 00:00:12,750

3
00:00:12,750 --> 00:00:16,170
Let's go ahead and move
on with trouble ticket 4.

4
00:00:16,170 --> 00:00:18,840
Once again, still
on MPLS topology 3.

5
00:00:18,840 --> 00:00:23,700
And according to
this, router 6 is not

6
00:00:23,700 --> 00:00:29,440
receiving any routes from
the customer A remote sites.

7
00:00:29,440 --> 00:00:31,680
So this is a fairly
straightforward ticket.

8
00:00:31,680 --> 00:00:34,170
Let's go ahead and
jump into router 6

9
00:00:34,170 --> 00:00:38,210
and see if we configure
what's going on.

10
00:00:38,210 --> 00:00:41,360
So of course, let's begin
by verifying our ticket.

11
00:00:41,360 --> 00:00:44,260
So here on router 6, we'll
just do a show IP route.

12
00:00:44,260 --> 00:00:46,120
It's saying we're not
getting any routes

13
00:00:46,120 --> 00:00:47,290
from the remote site.

14
00:00:47,290 --> 00:00:50,140
And we see here that that
appears to be correct.

15
00:00:50,140 --> 00:00:53,660
We have connected our local
routes, but that's it.

16
00:00:53,660 --> 00:00:57,700
We have no routes from
what should be OSPF.

17
00:00:57,700 --> 00:01:00,100
So I think the
first step would be

18
00:01:00,100 --> 00:01:03,790
to verify that we are running
OSPF here on router 6.

19
00:01:03,790 --> 00:01:08,080
So let's do a show IP
OSPF interface brief.

20
00:01:08,080 --> 00:01:10,870
And what we see here is that
we are, in fact, running

21
00:01:10,870 --> 00:01:14,020
OSPF on the gigabit
1 interface, which

22
00:01:14,020 --> 00:01:17,710
is our interface facing the
service provider or router 1.

23
00:01:17,710 --> 00:01:20,870
So that appears to be correct.

24
00:01:20,870 --> 00:01:24,070
Let's do a show
IP OSPF neighbor.

25
00:01:24,070 --> 00:01:26,320
Let's see if we have a
neighborship with router 1.

26
00:01:26,320 --> 00:01:28,360
We can see that, in fact, we do.

27
00:01:28,360 --> 00:01:29,800
The neighbor state is full.

28
00:01:29,800 --> 00:01:33,340
And of course, that is connected
out of our gigabit 1 interface

29
00:01:33,340 --> 00:01:35,090
as we would expect.

30
00:01:35,090 --> 00:01:38,560
So we do appear to
be running OSPF,

31
00:01:38,560 --> 00:01:41,710
and we do appear to
have neighborships.

32
00:01:41,710 --> 00:01:45,670
Let's try a show
IP OSPF database

33
00:01:45,670 --> 00:01:47,530
because it is
possible that we're

34
00:01:47,530 --> 00:01:51,190
receiving the updates through
OSPF, but for whatever reason,

35
00:01:51,190 --> 00:01:53,360
they're not making it
to the routing table.

36
00:01:53,360 --> 00:01:56,320
So if we look at our
show IP OSPF database,

37
00:01:56,320 --> 00:02:01,750
we do see that we have a
type I LSA here for router 1.

38
00:02:01,750 --> 00:02:05,470
So again, we are getting
information from that device,

39
00:02:05,470 --> 00:02:08,000
but that's all that we have.

40
00:02:08,000 --> 00:02:10,600
So let's try and get a little
bit more information from that.

41
00:02:10,600 --> 00:02:13,690
Let's ask for router 10.1.1.1.

42
00:02:13,690 --> 00:02:17,650
So again, we definitely
are getting a type I LSA.

43
00:02:17,650 --> 00:02:21,220
It's actually advertising
the point-to-point network

44
00:02:21,220 --> 00:02:24,190
between router 6 and router 1.

45
00:02:24,190 --> 00:02:28,780
Now, that wouldn't show up
in OSPF because, well, that's

46
00:02:28,780 --> 00:02:30,220
a connected network.

47
00:02:30,220 --> 00:02:33,860
But unfortunately, that's
all it's advertising to us.

48
00:02:33,860 --> 00:02:38,680
And if we, of course,
did a show IP OSPF rib,

49
00:02:38,680 --> 00:02:42,370
we see that, yeah, we know
about our own loopback.

50
00:02:42,370 --> 00:02:43,480
Of course, we do.

51
00:02:43,480 --> 00:02:48,580
We know about 10.100.6 that's
also connected to this device

52
00:02:48,580 --> 00:02:50,440
on loopback 100.

53
00:02:50,440 --> 00:02:54,460
And we know about the
192.168.16.0, the link

54
00:02:54,460 --> 00:02:56,470
between router 1 and router 6.

55
00:02:56,470 --> 00:02:59,440
But none of these are the
routes from the other side.

56
00:02:59,440 --> 00:03:01,870
And we can also see
that none of these

57
00:03:01,870 --> 00:03:04,540
are installed in the global rib.

58
00:03:04,540 --> 00:03:07,420
Of course, the reason they're
not installed in the global rib

59
00:03:07,420 --> 00:03:11,530
is even though we're either
learning them from OSPF

60
00:03:11,530 --> 00:03:15,010
or this router's
injecting them into OSPF,

61
00:03:15,010 --> 00:03:17,920
one way or the other,
all three of these

62
00:03:17,920 --> 00:03:20,260
are local on this router.

63
00:03:20,260 --> 00:03:21,980
They're connected interfaces.

64
00:03:21,980 --> 00:03:24,520
So of course, we're not
going to follow OSPF

65
00:03:24,520 --> 00:03:26,480
when we have connected routes.

66
00:03:26,480 --> 00:03:29,770
So the main point
in all of this, OSPF

67
00:03:29,770 --> 00:03:33,730
looks like it's functioning
perfectly fine on router 6.

68
00:03:33,730 --> 00:03:36,880
It looks like we have a
neighborship with router 1.

69
00:03:36,880 --> 00:03:39,790
And router 1 is,
in fact, sending us

70
00:03:39,790 --> 00:03:43,090
database entries or LSAs.

71
00:03:43,090 --> 00:03:45,130
So it seems like
it's probably time

72
00:03:45,130 --> 00:03:47,770
to jump over to router 1 and
maybe get a look at what's

73
00:03:47,770 --> 00:03:50,450
going on over there.

74
00:03:50,450 --> 00:03:52,540
So here on router 1,
let's see if we even

75
00:03:52,540 --> 00:03:54,830
have the routes in the VRF.

76
00:03:54,830 --> 00:03:59,440
So let's do a show IP route
for the VRF customer A.

77
00:03:59,440 --> 00:04:01,990
So what we see here
is a combination

78
00:04:01,990 --> 00:04:05,350
of OSPF and BGP updates.

79
00:04:05,350 --> 00:04:07,780
Now in this case, of
course, the OSPF routes

80
00:04:07,780 --> 00:04:09,700
are coming from router 6.

81
00:04:09,700 --> 00:04:12,010
So those aren't what
we're really concerned

82
00:04:12,010 --> 00:04:12,790
about right now.

83
00:04:12,790 --> 00:04:15,590
We're more worried
about the BGP updates.

84
00:04:15,590 --> 00:04:18,820
So we see here that we do,
in fact, have BGP updates.

85
00:04:18,820 --> 00:04:21,010
We can, of course, filter this.

86
00:04:21,010 --> 00:04:25,280
Router 1 is learning the
routes from the other side.

87
00:04:25,280 --> 00:04:29,290
So let's see if it's actually
putting them into OSPF.

88
00:04:29,290 --> 00:04:33,430
So let's do a show IP
OSPF for the process 100.

89
00:04:33,430 --> 00:04:35,800
That's the customer's process.

90
00:04:35,800 --> 00:04:40,380
If we didn't remember, we
could, of course, look.

91
00:04:40,380 --> 00:04:44,040
We could start with
a show IP protocol.

92
00:04:44,040 --> 00:04:47,910
So we can see that we have
the routing process OSPF 100.

93
00:04:47,910 --> 00:04:51,070
So if we didn't remember exactly
which one it was, of course,

94
00:04:51,070 --> 00:04:52,330
we could look.

95
00:04:52,330 --> 00:04:53,850
But now that we
verified it, we can

96
00:04:53,850 --> 00:04:57,930
do a show IP OSPF 100 database.

97
00:04:57,930 --> 00:05:02,080
And let's filter
by self-originated.

98
00:05:02,080 --> 00:05:06,540
So again, here's a spectacularly
empty list of all of the LSAs

99
00:05:06,540 --> 00:05:09,570
that we're generating
here on router 1.

100
00:05:09,570 --> 00:05:11,790
So clearly, there's
a problem here

101
00:05:11,790 --> 00:05:14,520
with getting the
routes from BGP,

102
00:05:14,520 --> 00:05:18,120
which we do have into OSPF.

103
00:05:18,120 --> 00:05:21,150
So there's something going
on with the redistribution.

104
00:05:21,150 --> 00:05:22,680
Maybe it's being filtered.

105
00:05:22,680 --> 00:05:24,640
Maybe it's not
configured at all.

106
00:05:24,640 --> 00:05:26,280
There's a couple
of options here,

107
00:05:26,280 --> 00:05:28,080
but it's probably
time to take a look

108
00:05:28,080 --> 00:05:31,830
at how it's actually configured
to do that redistribution.

109
00:05:31,830 --> 00:05:34,440
So let's go ahead
and do a show run.

110
00:05:34,440 --> 00:05:37,620
And we'll begin with OSPF.

111
00:05:37,620 --> 00:05:40,800
Of course, we'll be looking
for OSPF process 100.

112
00:05:40,800 --> 00:05:44,370
We do see that it is in
the proper customer VRF.

113
00:05:44,370 --> 00:05:46,410
Our domain ID is configured.

114
00:05:46,410 --> 00:05:48,690
Under the address
family under area 0,

115
00:05:48,690 --> 00:05:51,690
we do have our interface, and
it is configured for point

116
00:05:51,690 --> 00:05:53,020
to point.

117
00:05:53,020 --> 00:05:58,180
But what we do not have is
any redistribution of BGP.

118
00:05:58,180 --> 00:06:01,240
So this definitely
appears to be a problem.

119
00:06:01,240 --> 00:06:05,500
Let's go ahead and fix that and
see if it resolves our issue.

120
00:06:05,500 --> 00:06:07,830
So we'll go into
configuration mode,

121
00:06:07,830 --> 00:06:12,030
router OSPF 100 into
the VRF for customer A,

122
00:06:12,030 --> 00:06:16,410
and we'll say
redistribute BGP 100.

123
00:06:16,410 --> 00:06:18,210
Commit our changes.

124
00:06:18,210 --> 00:06:20,320
And exit configuration.

125
00:06:20,320 --> 00:06:22,740
So now that we have our
redistribution done,

126
00:06:22,740 --> 00:06:25,440
let's go ahead and jump
back over to router 6

127
00:06:25,440 --> 00:06:28,420
and see if this is
resolved our issue.

128
00:06:28,420 --> 00:06:32,530
So on router 6, if we do our
show IP OSPF database again,

129
00:06:32,530 --> 00:06:35,920
we see that clearly now, we
have a whole bunch more entries.

130
00:06:35,920 --> 00:06:40,090
And if we do our show
IP OSPF rib again,

131
00:06:40,090 --> 00:06:43,500
we can see that now, we have
a lot of these prefixes that

132
00:06:43,500 --> 00:06:47,040
are actually installed
in the global rib, which

133
00:06:47,040 --> 00:06:51,570
means if we do our show IP
route, we'll filter by OSPF.

134
00:06:51,570 --> 00:06:54,660
We now have all
of our OIA entries

135
00:06:54,660 --> 00:06:57,130
for the networks
on the other side.

136
00:06:57,130 --> 00:07:01,270
So it seems like this
completely resolves this ticket.

137
00:07:01,270 --> 00:07:04,500
So in this video, we saw
how missing something

138
00:07:04,500 --> 00:07:09,330
as simple as redistribution in
our MPLS layer 3 environment

139
00:07:09,330 --> 00:07:12,420
can, of course, break
the entire thing.

140
00:07:12,420 --> 00:07:15,510
We were missing all of
our routes on router 6

141
00:07:15,510 --> 00:07:18,900
simply because
router 1 wasn't doing

142
00:07:18,900 --> 00:07:20,790
the proper redistribution.

143
00:07:20,790 --> 00:07:24,480
Now, we didn't look at this
specifically in this ticket.

144
00:07:24,480 --> 00:07:27,180
However, from our
previous tickets,

145
00:07:27,180 --> 00:07:28,950
we already know the
routes we're getting

146
00:07:28,950 --> 00:07:32,670
from router 6 to the other
side because, well, that

147
00:07:32,670 --> 00:07:35,410
had some issues too, and
we've already resolved those.

148
00:07:35,410 --> 00:07:37,110
So we already know
that redistribution

149
00:07:37,110 --> 00:07:38,520
was working one way.

150
00:07:38,520 --> 00:07:40,660
It just wasn't
working the other.

151
00:07:40,660 --> 00:07:42,390
So now that we
have this resolved,

152
00:07:42,390 --> 00:07:46,870
we have the routes on router
6 just as we're supposed to.

153
00:07:46,870 --> 00:07:49,110
I hope this has been
informative for you,

154
00:07:49,110 --> 00:07:52,160
and I'd like to thank
you for viewing.

155
00:07:52,160 --> 00:07:56,000