1
00:00:00,000 --> 00:00:12,510

2
00:00:12,510 --> 00:00:15,930
So next up, we have
trouble ticket 5.

3
00:00:15,930 --> 00:00:18,940
This one is a traffic
engineering ticket.

4
00:00:18,940 --> 00:00:23,190
Therefore, this is
on MPLS topology 5.

5
00:00:23,190 --> 00:00:26,100
And we don't have a
common core protocol.

6
00:00:26,100 --> 00:00:28,530
This time, we have
a domain 1 which

7
00:00:28,530 --> 00:00:34,250
is running IS-IS and a domain
2 which is running OSPF.

8
00:00:34,250 --> 00:00:37,370
Also keep in mind that we
have a route reflector where

9
00:00:37,370 --> 00:00:44,660
we're running BGP, with routers
7 and 8, for our unicast IPv4

10
00:00:44,660 --> 00:00:50,520
and routers 1, 2, 5, and
6 for BGP link-state.

11
00:00:50,520 --> 00:00:53,750
So all of that said, let's
take a look at our ticket.

12
00:00:53,750 --> 00:01:01,370
This ticket says that R8
cannot reach 100.7.7.7,

13
00:01:01,370 --> 00:01:05,120
which is actually a network
over here on router 7.

14
00:01:05,120 --> 00:01:07,820
As usual, let's start
by verifying the ticket,

15
00:01:07,820 --> 00:01:12,530
and then we'll jump into
our troubleshooting.

16
00:01:12,530 --> 00:01:14,860
So to verify the
ticket, we'll go ahead

17
00:01:14,860 --> 00:01:17,980
and trace to the 100.7.7.7.

18
00:01:17,980 --> 00:01:21,340
We'll source it from our
loopback 100 interface.

19
00:01:21,340 --> 00:01:25,930
Remember, this is reachable over
a traffic engineering tunnel.

20
00:01:25,930 --> 00:01:29,770
The only two networks
available across that tunnel

21
00:01:29,770 --> 00:01:35,330
should be the 100.7.7.7 and
our loopback 100 interface,

22
00:01:35,330 --> 00:01:37,930
which is 100.8.8.8.

23
00:01:37,930 --> 00:01:40,210
So we need to source
this from our loopback

24
00:01:40,210 --> 00:01:43,580
100 or it wouldn't
work either way.

25
00:01:43,580 --> 00:01:46,660
So as we can see,
this is going nowhere.

26
00:01:46,660 --> 00:01:48,830
I let it go through
about five hops there

27
00:01:48,830 --> 00:01:50,650
and then it just broke
out of the trace.

28
00:01:50,650 --> 00:01:52,940
This is not five hops away.

29
00:01:52,940 --> 00:01:55,630
So this should not
take this many hops.

30
00:01:55,630 --> 00:01:57,740
This is clearly not working.

31
00:01:57,740 --> 00:02:01,690
So when a trace goes literally
nowhere on even the first hop,

32
00:02:01,690 --> 00:02:05,290
it's always a good idea to
check your own local routing.

33
00:02:05,290 --> 00:02:07,540
Because if I don't
know where to send it,

34
00:02:07,540 --> 00:02:09,639
then there's not even
going to be a first hop,

35
00:02:09,639 --> 00:02:11,180
let alone a last hop.

36
00:02:11,180 --> 00:02:15,620
So a show ip route
for the 100.7.7.7

37
00:02:15,620 --> 00:02:18,780
would probably be a
good place to start.

38
00:02:18,780 --> 00:02:22,640
As we can see, this is
not a spectacular answer.

39
00:02:22,640 --> 00:02:25,370
It's telling us that we
don't have the network.

40
00:02:25,370 --> 00:02:26,310
OK.

41
00:02:26,310 --> 00:02:28,860
Well, we should be
learning it through BGP.

42
00:02:28,860 --> 00:02:32,012
So let's do a show ip bgp.

43
00:02:32,012 --> 00:02:35,700
And what we see here is we have
an entry for our own loopback,

44
00:02:35,700 --> 00:02:40,880
which I mentioned
earlier, the 100.8.8.0/24.

45
00:02:40,880 --> 00:02:45,560
But we don't have the 100.7.7.7.

46
00:02:45,560 --> 00:02:48,480
Now remember, this is
supposed to be advertised

47
00:02:48,480 --> 00:02:50,480
and we're supposed to
have a traffic engineering

48
00:02:50,480 --> 00:02:52,530
tunnel based on that.

49
00:02:52,530 --> 00:02:54,860
So without the
route, we probably

50
00:02:54,860 --> 00:02:56,370
don't even have the tunnel.

51
00:02:56,370 --> 00:02:58,170
Let's verify that.

52
00:02:58,170 --> 00:03:02,600
So if we do a show mpls
traffic tunnel, as suspected,

53
00:03:02,600 --> 00:03:04,650
we don't even have a tunnel up.

54
00:03:04,650 --> 00:03:07,170
So this is definitely
not going to work.

55
00:03:07,170 --> 00:03:10,300
We're not getting the
route through BGP.

56
00:03:10,300 --> 00:03:12,300
So since we're not
getting the update,

57
00:03:12,300 --> 00:03:16,230
it's probably not a bad idea to
go look at the route reflector

58
00:03:16,230 --> 00:03:18,000
and see if the route
reflector is getting

59
00:03:18,000 --> 00:03:21,420
the update since that's sort
of the central point of all

60
00:03:21,420 --> 00:03:22,620
of the BGP updates.

61
00:03:22,620 --> 00:03:26,070
Always a great place to check
if we're missing updates, to see

62
00:03:26,070 --> 00:03:27,700
if the route reflector has it.

63
00:03:27,700 --> 00:03:30,920
So let's go check out
the route reflector.

64
00:03:30,920 --> 00:03:34,130
So here we'll still
do a show IP BGP.

65
00:03:34,130 --> 00:03:36,190
And interestingly,
what we see here

66
00:03:36,190 --> 00:03:38,290
is the route
reflector actually has

67
00:03:38,290 --> 00:03:45,130
both prefixes, the
100.7.7.0 and the 100.8.8.0.

68
00:03:45,130 --> 00:03:47,920
And they're both
selected as best,

69
00:03:47,920 --> 00:03:52,150
which means it really should
be sending this to router 8.

70
00:03:52,150 --> 00:03:53,750
Let's check.

71
00:03:53,750 --> 00:03:57,370
Let's do a show bgp
neighbor for 10.8.8.8

72
00:03:57,370 --> 00:03:59,840
and we'll do advertised routes.

73
00:03:59,840 --> 00:04:03,280
So what we see here is it's
actually advertising both

74
00:04:03,280 --> 00:04:06,340
of these prefixes to router 8.

75
00:04:06,340 --> 00:04:09,370
So maybe we should dig in a
little bit more on router 8

76
00:04:09,370 --> 00:04:12,040
to see why it's not
getting this update.

77
00:04:12,040 --> 00:04:13,900
Because it looks like
the route reflector

78
00:04:13,900 --> 00:04:15,410
is, in fact, sending it.

79
00:04:15,410 --> 00:04:17,410
So let's go back to router 8.

80
00:04:17,410 --> 00:04:18,910
And let's turn on a debug.

81
00:04:18,910 --> 00:04:24,310
Let's do a debug IP BGP update
and then clear a BGP table.

82
00:04:24,310 --> 00:04:27,550
We'll just do a soft end, and
we'll do it for all neighbors

83
00:04:27,550 --> 00:04:30,490
since router 8 only has
one neighbor anyway.

84
00:04:30,490 --> 00:04:34,600
And here, we see a very
important entry in our debug.

85
00:04:34,600 --> 00:04:37,300
Right here, we see
that we are, in fact,

86
00:04:37,300 --> 00:04:45,280
receiving the 100.7.7.0/24 but
it's denied due to a route map.

87
00:04:45,280 --> 00:04:48,620
So that could be a
significant problem.

88
00:04:48,620 --> 00:04:50,480
So let's take a look
at our configuration.

89
00:04:50,480 --> 00:04:53,170
Let's do a show run section bgp.

90
00:04:53,170 --> 00:04:55,330
And we see that we
do, in fact, have

91
00:04:55,330 --> 00:05:01,250
a route map, IPv4_IN, applied
in the inbound direction.

92
00:05:01,250 --> 00:05:07,280
So let's say-- do show
route map IPv4_IN.

93
00:05:07,280 --> 00:05:10,030
And the important thing
we see in this route map

94
00:05:10,030 --> 00:05:17,420
is we're matching on a community
list called CL_LL_TRAFFIC.

95
00:05:17,420 --> 00:05:20,140
So we should probably see
what that community list says.

96
00:05:20,140 --> 00:05:25,762
So we'll say show ip
community-list CL_LL_TRAFFIC.

97
00:05:25,762 --> 00:05:28,940

98
00:05:28,940 --> 00:05:33,580
So this is permitting the
community string 100:10.

99
00:05:33,580 --> 00:05:35,350
This all looks appropriate.

100
00:05:35,350 --> 00:05:37,340
This all looks correct.

101
00:05:37,340 --> 00:05:39,580
So a good place to go
from here would be back

102
00:05:39,580 --> 00:05:40,960
to the route reflector.

103
00:05:40,960 --> 00:05:43,810
Let's look at the
detail on that prefix

104
00:05:43,810 --> 00:05:46,490
and see if it has
this community on it.

105
00:05:46,490 --> 00:05:52,790
So now let's do our show
ip bgp for the 100.7.7.0.

106
00:05:52,790 --> 00:05:55,610
And what we see here
is there's actually

107
00:05:55,610 --> 00:05:58,130
no community on this at all.

108
00:05:58,130 --> 00:06:01,550
And, of course, there
needs to be the 100:10.

109
00:06:01,550 --> 00:06:03,060
It's not here.

110
00:06:03,060 --> 00:06:07,170
So that explains why router
8 is filtering out the route.

111
00:06:07,170 --> 00:06:09,080
So if it's not on
the update, that

112
00:06:09,080 --> 00:06:12,390
means that router 7 must
not be putting it on.

113
00:06:12,390 --> 00:06:14,900
Let's go check out router 7 now.

114
00:06:14,900 --> 00:06:17,450
So on router 7, let's
just go right for the show

115
00:06:17,450 --> 00:06:20,900
run section bgp and see
what it's configured to do.

116
00:06:20,900 --> 00:06:24,830
So actually, what we see here
is on the network statement

117
00:06:24,830 --> 00:06:29,270
where it's bringing
the 100.7.7.0 into BGP,

118
00:06:29,270 --> 00:06:34,800
that's being run through a
route map called IPv4_OUT.

119
00:06:34,800 --> 00:06:37,520
So let's see what that
route map is doing.

120
00:06:37,520 --> 00:06:42,810
What we see is it's configured
to set the community to 100:10,

121
00:06:42,810 --> 00:06:44,460
which is correct.

122
00:06:44,460 --> 00:06:47,130
So let's see if it's
actually doing it.

123
00:06:47,130 --> 00:06:51,440
Let's do a show ip bgp for
our own injected route.

124
00:06:51,440 --> 00:06:54,630
So we see right here that it is,
in fact, putting the community

125
00:06:54,630 --> 00:06:57,420
100:10 on the update.

126
00:06:57,420 --> 00:07:00,450
Yet we've also seen that
that's not making it

127
00:07:00,450 --> 00:07:02,170
to the route reflector.

128
00:07:02,170 --> 00:07:06,100
So let's take a look at our
BGP configuration again.

129
00:07:06,100 --> 00:07:08,530
And if we look over
this configuration,

130
00:07:08,530 --> 00:07:11,240
we can actually see the problem.

131
00:07:11,240 --> 00:07:16,220
Keep in mind that the
default behavior of iOS XE

132
00:07:16,220 --> 00:07:19,760
is actually to strip the
community strings off

133
00:07:19,760 --> 00:07:21,660
of outbound updates.

134
00:07:21,660 --> 00:07:26,060
So ironically enough, router
7 is configured properly

135
00:07:26,060 --> 00:07:28,760
to put the community
string onto the update.

136
00:07:28,760 --> 00:07:31,400
But as soon as it sends
it to the route reflector,

137
00:07:31,400 --> 00:07:33,710
it's then stripping
off the community.

138
00:07:33,710 --> 00:07:37,730
We have to actually configure
this to send the community

139
00:07:37,730 --> 00:07:39,300
to the route reflector.

140
00:07:39,300 --> 00:07:42,850
So let's go ahead and
put that fix in place.

141
00:07:42,850 --> 00:07:45,540
So we'll simply go
into configuration mode

142
00:07:45,540 --> 00:07:48,150
in the router_bgp 100.

143
00:07:48,150 --> 00:07:53,100
And then for the neighbor
10.11.11.11, we have to say,

144
00:07:53,100 --> 00:07:54,480
send-community.

145
00:07:54,480 --> 00:07:56,560
And then of course,
you have a choice here.

146
00:07:56,560 --> 00:07:59,520
You can do both
extended or standard.

147
00:07:59,520 --> 00:08:01,570
We only really need standard.

148
00:08:01,570 --> 00:08:03,630
However, I usually
just turn on both

149
00:08:03,630 --> 00:08:06,030
if we're turning on
the feature anyway.

150
00:08:06,030 --> 00:08:08,800
So let's go ahead and do that.

151
00:08:08,800 --> 00:08:10,980
We'll exit configuration.

152
00:08:10,980 --> 00:08:13,740
And we'll do an
outbound soft clear

153
00:08:13,740 --> 00:08:17,920
to push these new changes
up to the other devices.

154
00:08:17,920 --> 00:08:21,600
So that said, let's go take
a look at the route reflector

155
00:08:21,600 --> 00:08:25,020
and see if it has the
community string now.

156
00:08:25,020 --> 00:08:28,210
So we'll simply look at
our same command again.

157
00:08:28,210 --> 00:08:33,630
And now we see right here that
the community is set to 100:10

158
00:08:33,630 --> 00:08:35,320
as it's supposed to be.

159
00:08:35,320 --> 00:08:36,850
So this looks good.

160
00:08:36,850 --> 00:08:40,980
Let's go see if it showed
up on router 8 now.

161
00:08:40,980 --> 00:08:44,090
So we can even see here on
the debug, which we still

162
00:08:44,090 --> 00:08:46,790
had running, that
we've now received

163
00:08:46,790 --> 00:08:50,300
the update for 100.7.7.0.

164
00:08:50,300 --> 00:08:55,940
We can see right here where the
community is now set to 100:10.

165
00:08:55,940 --> 00:08:59,960
And we see right here where it's
actually installed that route

166
00:08:59,960 --> 00:09:01,680
into the routing table.

167
00:09:01,680 --> 00:09:04,580
So let's go ahead and
turn off our debugging.

168
00:09:04,580 --> 00:09:07,940
Let's do a show ip
bgp for that update.

169
00:09:07,940 --> 00:09:11,360
And we do, in fact, see here
that the community is set

170
00:09:11,360 --> 00:09:15,440
and we're getting the binding
SID based on our traffic

171
00:09:15,440 --> 00:09:17,270
engineering tunnel.

172
00:09:17,270 --> 00:09:19,820
If we do a show ip
route for the update,

173
00:09:19,820 --> 00:09:22,500
we see that it's in our
routing table as well.

174
00:09:22,500 --> 00:09:24,950
So let's see if our
tunnel is up now.

175
00:09:24,950 --> 00:09:29,370

176
00:09:29,370 --> 00:09:34,670
So we see that Tunnel1000, with
the destination of 10.7.7.7,

177
00:09:34,670 --> 00:09:38,270
is, in fact, admin
up, operational up,

178
00:09:38,270 --> 00:09:41,750
the path is valid, the
signaling is connected,

179
00:09:41,750 --> 00:09:44,090
and it's using path option 1--

180
00:09:44,090 --> 00:09:46,910
segment routing with PCE.

181
00:09:46,910 --> 00:09:49,910
So this looks like
everything is operational.

182
00:09:49,910 --> 00:09:52,970
Let's go ahead and test
our original ticket.

183
00:09:52,970 --> 00:09:57,380
Let's do our trace to 100.7.7.7,
sourcing it from our loopback

184
00:09:57,380 --> 00:10:00,090
100 interface.

185
00:10:00,090 --> 00:10:05,570
So interestingly, based on this
trace, it's still not working.

186
00:10:05,570 --> 00:10:08,600
Now, keep in mind,
this traffic has

187
00:10:08,600 --> 00:10:10,700
to be able to go
both directions.

188
00:10:10,700 --> 00:10:12,870
We've done all of
our verifications

189
00:10:12,870 --> 00:10:16,310
so far on router 8 and
made sure the router 8

190
00:10:16,310 --> 00:10:17,910
tunnel is up and so on.

191
00:10:17,910 --> 00:10:20,390
But these are
unidirectional tunnels.

192
00:10:20,390 --> 00:10:23,220
We need a tunnel on the
other direction as well.

193
00:10:23,220 --> 00:10:26,540
So since everything
appears to be OK here,

194
00:10:26,540 --> 00:10:29,180
and that doesn't
necessarily mean that it is.

195
00:10:29,180 --> 00:10:31,340
There could still
be other problems.

196
00:10:31,340 --> 00:10:33,740
But I think the
next logical step

197
00:10:33,740 --> 00:10:37,130
would be to check the path
for the return traffic.

198
00:10:37,130 --> 00:10:40,440
That seems to be the most
logical thing to be wrong here.

199
00:10:40,440 --> 00:10:43,190
So let's go over to
router 7 and take a look

200
00:10:43,190 --> 00:10:46,330
at that return tunnel.

201
00:10:46,330 --> 00:10:49,290
So if we do our show
mpls traffic tunnel,

202
00:10:49,290 --> 00:10:50,760
well, there we have it.

203
00:10:50,760 --> 00:10:53,670
There's no tunnel
on this side either.

204
00:10:53,670 --> 00:10:56,020
Well, let's go through
the routine again.

205
00:10:56,020 --> 00:11:00,780
So let's do our show ip
bgp for the 100.8.8.0.

206
00:11:00,780 --> 00:11:03,190
And again, the network's
not in the table.

207
00:11:03,190 --> 00:11:05,950
So we've sort of
seen this already.

208
00:11:05,950 --> 00:11:08,550
Let's just verify that
it's the same problem.

209
00:11:08,550 --> 00:11:12,970
If we do a show run
section bgp, once again,

210
00:11:12,970 --> 00:11:16,140
we see we have a route
map applied inbound.

211
00:11:16,140 --> 00:11:18,450
If we just do a
show route map, we

212
00:11:18,450 --> 00:11:20,310
see that that
inbound route map is

213
00:11:20,310 --> 00:11:22,320
matching on the community list.

214
00:11:22,320 --> 00:11:24,690
If we do a show
ip community list,

215
00:11:24,690 --> 00:11:27,210
we see that, again, it's
permitting that same community

216
00:11:27,210 --> 00:11:27,880
string.

217
00:11:27,880 --> 00:11:30,300
So this appears to
be the same issue.

218
00:11:30,300 --> 00:11:33,670
We'll verify it again real
quickly on the route reflector.

219
00:11:33,670 --> 00:11:36,960
So this time we'll
look at the 8.8.0.

220
00:11:36,960 --> 00:11:39,520
Once again, no community string.

221
00:11:39,520 --> 00:11:41,640
So let's go back to router 8.

222
00:11:41,640 --> 00:11:44,250
We'll do a show run section bgp.

223
00:11:44,250 --> 00:11:47,980
And no big surprise,
this router is also not

224
00:11:47,980 --> 00:11:50,150
configured to send
the community.

225
00:11:50,150 --> 00:11:52,240
So let's go ahead and fix that.

226
00:11:52,240 --> 00:11:54,460
We'll clear our
outbound updates.

227
00:11:54,460 --> 00:11:57,610
Since we're pretty confident
that this is the same problem,

228
00:11:57,610 --> 00:12:00,010
we'll skip all the other
verification in the middle.

229
00:12:00,010 --> 00:12:02,440
Let's just go right
back to router 7.

230
00:12:02,440 --> 00:12:04,540
Look at the BGP update.

231
00:12:04,540 --> 00:12:06,700
We see that it has the
community string here

232
00:12:06,700 --> 00:12:09,730
and, more importantly,
that we have the update.

233
00:12:09,730 --> 00:12:11,980
Let's verify our tunnel.

234
00:12:11,980 --> 00:12:14,890
We see that, just like
router 8, this tunnel

235
00:12:14,890 --> 00:12:16,760
is up and operational.

236
00:12:16,760 --> 00:12:20,260
So now let's try our
original ticket once again.

237
00:12:20,260 --> 00:12:22,910
Maybe now it actually works.

238
00:12:22,910 --> 00:12:25,840
So back here on router 8,
let's do our trace again

239
00:12:25,840 --> 00:12:27,670
and hope for better luck.

240
00:12:27,670 --> 00:12:31,390
So as we can see from this
update, now it's working.

241
00:12:31,390 --> 00:12:37,210
We have reachability to
100.7.7.7 from router 8

242
00:12:37,210 --> 00:12:38,830
as we're supposed to.

243
00:12:38,830 --> 00:12:44,940
Therefore, I would consider this
to be trouble ticket 5 solved.

244
00:12:44,940 --> 00:12:48,980
So in this video, we saw
the result of routers

245
00:12:48,980 --> 00:12:52,550
not configured to send
the BGP community string.

246
00:12:52,550 --> 00:12:55,670
Since we were using the
community string for route

247
00:12:55,670 --> 00:12:58,340
filtering, if it
doesn't get sent,

248
00:12:58,340 --> 00:13:00,380
that means all the
routes are going

249
00:13:00,380 --> 00:13:03,140
to get filtered
out or, at least,

250
00:13:03,140 --> 00:13:06,690
not being used for traffic
engineering tunnels.

251
00:13:06,690 --> 00:13:08,720
Now, the use of
community strings

252
00:13:08,720 --> 00:13:10,520
is technically optional.

253
00:13:10,520 --> 00:13:13,700
But we don't generally want
traffic engineering tunnels

254
00:13:13,700 --> 00:13:16,910
built for every
single BGP prefix.

255
00:13:16,910 --> 00:13:18,770
We want to be able
to control that,

256
00:13:18,770 --> 00:13:21,230
and that's why we use
the community strings.

257
00:13:21,230 --> 00:13:24,920
We just have to
make sure on iOS XE

258
00:13:24,920 --> 00:13:28,340
that we configure it to
then send those communities.

259
00:13:28,340 --> 00:13:31,100
Because as you saw,
it will strip off

260
00:13:31,100 --> 00:13:34,910
even the ones that that router
itself put on the update.

261
00:13:34,910 --> 00:13:37,610
But once we configured it
to send the community up

262
00:13:37,610 --> 00:13:40,160
to the route reflector,
then everything

263
00:13:40,160 --> 00:13:43,340
started working and
everything came backup.

264
00:13:43,340 --> 00:13:45,600
Of course, we had to
do it on both sides.

265
00:13:45,600 --> 00:13:49,620
But regardless, we got
this up and operational.

266
00:13:49,620 --> 00:13:51,840
I hope this has been
informative for you.

267
00:13:51,840 --> 00:13:55,010
And I'd like to thank
you for viewing.

268
00:13:55,010 --> 00:13:58,000