1
00:00:00,000 --> 00:00:00,994

2
00:00:00,994 --> 00:00:04,473
[AUDIO LOGO]

3
00:00:04,473 --> 00:00:11,950

4
00:00:11,950 --> 00:00:15,460
So we'll start off here
on Trouble Ticket 1.

5
00:00:15,460 --> 00:00:17,470
And on Trouble
Ticket 1, we're going

6
00:00:17,470 --> 00:00:20,200
to be using BGP Topology 1.

7
00:00:20,200 --> 00:00:22,600
Actually, all of
these tickets are

8
00:00:22,600 --> 00:00:25,600
going to use BGP
Topology 1, so we

9
00:00:25,600 --> 00:00:27,650
won't point it out every time.

10
00:00:27,650 --> 00:00:29,260
But that is the
topology that you

11
00:00:29,260 --> 00:00:31,030
want to have
convenient when we're

12
00:00:31,030 --> 00:00:32,650
going through these tickets.

13
00:00:32,650 --> 00:00:35,560
So what's the actual
essence of this ticket?

14
00:00:35,560 --> 00:00:38,650
Well, the tickets going to be
listed down here at the bottom.

15
00:00:38,650 --> 00:00:42,430
And the ticket is that
router 5 is supposed

16
00:00:42,430 --> 00:00:46,990
to have a neighborship
to router 1 and router 2,

17
00:00:46,990 --> 00:00:49,270
but they are down.

18
00:00:49,270 --> 00:00:55,690
So router 5 is supposed to
be peered up with R1 and R2.

19
00:00:55,690 --> 00:00:58,450
But according to our
ticket, this isn't working.

20
00:00:58,450 --> 00:01:00,700
Now, another point
of information

21
00:01:00,700 --> 00:01:03,310
that you would hopefully be
able to get out of documentation

22
00:01:03,310 --> 00:01:06,460
if you didn't know this,
but in our environment,

23
00:01:06,460 --> 00:01:10,870
both of these routers are
in fact route reflectors.

24
00:01:10,870 --> 00:01:14,380
That's why router 5 would
only be peering with router 1

25
00:01:14,380 --> 00:01:15,670
and router 2.

26
00:01:15,670 --> 00:01:18,050
So as we get in
and look at this,

27
00:01:18,050 --> 00:01:21,250
we'll see that it's not
neighbors with routers 3 and 4

28
00:01:21,250 --> 00:01:24,590
either, but it's also
not supposed to be.

29
00:01:24,590 --> 00:01:26,980
So let's go ahead and jump in.

30
00:01:26,980 --> 00:01:31,040
We'll, of course, always start
with verifying the ticket.

31
00:01:31,040 --> 00:01:34,480
So that means we
start on router 5.

32
00:01:34,480 --> 00:01:38,780
So let's start off with the
good old show ip bgp summary.

33
00:01:38,780 --> 00:01:42,580
And what we see is
router 1 is actually

34
00:01:42,580 --> 00:01:44,680
listed as being active.

35
00:01:44,680 --> 00:01:48,160
Router 2 is listed
as being idle.

36
00:01:48,160 --> 00:01:52,950
If we do the same command again,
we see that they now flip-flop.

37
00:01:52,950 --> 00:01:55,110
So both of these
routers are cycling

38
00:01:55,110 --> 00:01:58,580
between active and idle.

39
00:01:58,580 --> 00:02:01,970
Now, one of the first things
we want to check with BGP

40
00:02:01,970 --> 00:02:04,070
is that we have reachability.

41
00:02:04,070 --> 00:02:07,920
Now, we know that we have
a route to the destination,

42
00:02:07,920 --> 00:02:11,585
in this case,
10.1.1.1 and 10.2.2.2.

43
00:02:11,585 --> 00:02:14,330
The reason we know that
is it wouldn't even

44
00:02:14,330 --> 00:02:18,230
be trying to go active if
it didn't have the route.

45
00:02:18,230 --> 00:02:21,150
So we could verify
the route if we like,

46
00:02:21,150 --> 00:02:23,900
but we should already
know that it has one,

47
00:02:23,900 --> 00:02:27,150
or again, it wouldn't
even try to go active.

48
00:02:27,150 --> 00:02:30,050
It would be sitting in
idle the whole time,

49
00:02:30,050 --> 00:02:33,570
but that doesn't mean we
actually have reachability.

50
00:02:33,570 --> 00:02:37,150
So that should be probably one
of the first things we check.

51
00:02:37,150 --> 00:02:39,750
Let's do a ping 10.1.1.1.

52
00:02:39,750 --> 00:02:42,300
And we'll go ahead and
source that from our loopback

53
00:02:42,300 --> 00:02:45,360
since these are supposed to
be peering using loopbacks.

54
00:02:45,360 --> 00:02:47,310
We see that that's successful.

55
00:02:47,310 --> 00:02:50,390

56
00:02:50,390 --> 00:02:52,790
And we can also ping, too.

57
00:02:52,790 --> 00:02:55,890
So we have connections
between the devices.

58
00:02:55,890 --> 00:02:57,860
This is not a
layer 1, a layer 2,

59
00:02:57,860 --> 00:03:00,740
or a layer issue
from the perspective

60
00:03:00,740 --> 00:03:03,360
of at least being able to ping.

61
00:03:03,360 --> 00:03:05,240
So now would probably
be a good idea

62
00:03:05,240 --> 00:03:07,770
to go look at what the other
routers are seeing here.

63
00:03:07,770 --> 00:03:09,650
So let's go to router 1.

64
00:03:09,650 --> 00:03:12,500
We'll do our show
ip bgp summary here.

65
00:03:12,500 --> 00:03:17,420
And in relation to router
5, we have an idle.

66
00:03:17,420 --> 00:03:19,790
So let's check
its configuration.

67
00:03:19,790 --> 00:03:22,880
Let's just do a
show on router bgp.

68
00:03:22,880 --> 00:03:25,760
Looking at router 5
here, we see that it's

69
00:03:25,760 --> 00:03:28,820
using the neighbor-group
RRC, which stands

70
00:03:28,820 --> 00:03:30,690
for Route Reflector Client.

71
00:03:30,690 --> 00:03:33,140
And if we look at our
neighbor-group RRC,

72
00:03:33,140 --> 00:03:35,660
it does appear to be
configured properly.

73
00:03:35,660 --> 00:03:37,640
It's configuring the remote-as.

74
00:03:37,640 --> 00:03:40,460
We have our update
source set to Loopback0.

75
00:03:40,460 --> 00:03:42,260
And then under our
address family,

76
00:03:42,260 --> 00:03:45,020
it is configured with a
Route Reflector Client

77
00:03:45,020 --> 00:03:47,010
and next-hop-self.

78
00:03:47,010 --> 00:03:50,580
So fundamentally,
this looks correct.

79
00:03:50,580 --> 00:03:53,150
Let's go ahead and verify
router 5's configuration,

80
00:03:53,150 --> 00:03:55,430
as well, since we
didn't look at that.

81
00:03:55,430 --> 00:03:58,310
We'll just do a show
run section bgp.

82
00:03:58,310 --> 00:04:01,130
This is a fairly
straightforward configuration.

83
00:04:01,130 --> 00:04:02,960
It is definitely
set to be neighbored

84
00:04:02,960 --> 00:04:06,050
with 10.1.1.1 and 10.2.2.2.

85
00:04:06,050 --> 00:04:08,900
They both have the remote
as configured properly,

86
00:04:08,900 --> 00:04:11,690
and they're both
set to Loopback0.

87
00:04:11,690 --> 00:04:13,970
So far, everything's
looking good.

88
00:04:13,970 --> 00:04:15,630
So why don't we do this?

89
00:04:15,630 --> 00:04:18,829
Why don't we jump into
Wireshark and take a look

90
00:04:18,829 --> 00:04:22,590
if these devices are actually
communicating with each other?

91
00:04:22,590 --> 00:04:26,720
So here's a packet capture of
the traffic on that Ethernet

92
00:04:26,720 --> 00:04:28,100
segment.

93
00:04:28,100 --> 00:04:29,720
And here, we have a packet.

94
00:04:29,720 --> 00:04:32,810
Notice that it's actually
coming from router 5's

95
00:04:32,810 --> 00:04:40,130
physical address 172.16.35.5
going to router 1.

96
00:04:40,130 --> 00:04:44,120
And also, notice that
it's an ICMP message.

97
00:04:44,120 --> 00:04:46,190
Now, the reason
this is important

98
00:04:46,190 --> 00:04:50,300
is look over under
the Info section here,

99
00:04:50,300 --> 00:04:54,470
it says communication
administratively filtered.

100
00:04:54,470 --> 00:04:56,630
So we're actually
getting a message

101
00:04:56,630 --> 00:05:01,620
from router 5 telling us that
it's rejecting our traffic.

102
00:05:01,620 --> 00:05:04,430
So every time that
router 1 tries

103
00:05:04,430 --> 00:05:08,120
to send traffic to
router 5 and vice versa,

104
00:05:08,120 --> 00:05:09,960
notice what's happening.

105
00:05:09,960 --> 00:05:12,080
We're getting a lot
of send messages.

106
00:05:12,080 --> 00:05:14,430
We're getting SYN-ACK messages.

107
00:05:14,430 --> 00:05:16,880
And then we're getting
communication administratively

108
00:05:16,880 --> 00:05:17,660
filtered.

109
00:05:17,660 --> 00:05:20,930
So something is stopping
this communication

110
00:05:20,930 --> 00:05:24,650
from forming a TCP
three-way handshake.

111
00:05:24,650 --> 00:05:27,050
One side is going SYN-SYN-ACK.

112
00:05:27,050 --> 00:05:30,890
The other side is just
going SYN and staying there.

113
00:05:30,890 --> 00:05:33,050
It's never even
getting a SYN-ACK,

114
00:05:33,050 --> 00:05:35,810
instead it's getting
that the communication is

115
00:05:35,810 --> 00:05:37,430
administratively filtered.

116
00:05:37,430 --> 00:05:42,282
This sounds a lot like an ACL.

117
00:05:42,282 --> 00:05:46,730
So let's jump into router 5
and see if it does in fact

118
00:05:46,730 --> 00:05:49,070
have any ACLs configured
on that router

119
00:05:49,070 --> 00:05:52,970
because it really looks like
this traffic is being blocked

120
00:05:52,970 --> 00:05:54,650
based on our Wireshark output.

121
00:05:54,650 --> 00:05:57,200

122
00:05:57,200 --> 00:06:00,310
Let's do a show ip
interface gigabit 1.

123
00:06:00,310 --> 00:06:04,780
And notice right here, we
have an inbound access list

124
00:06:04,780 --> 00:06:07,270
called ACL filter.

125
00:06:07,270 --> 00:06:09,680
Let's take a look
at that access list.

126
00:06:09,680 --> 00:06:11,830
If we look at this
access list, we

127
00:06:11,830 --> 00:06:13,450
see that it's
permitting some things,

128
00:06:13,450 --> 00:06:18,830
like web traffic, FTP traffic,
SMTP traffic, and so on.

129
00:06:18,830 --> 00:06:22,810
However, what it's not
doing is permitting BGP.

130
00:06:22,810 --> 00:06:24,610
It's denying everything else.

131
00:06:24,610 --> 00:06:26,500
And based on the
number of matches

132
00:06:26,500 --> 00:06:29,950
we have there particularly
in a lab, that would probably

133
00:06:29,950 --> 00:06:32,980
indicate that we're getting
a lot of denied traffic

134
00:06:32,980 --> 00:06:34,520
on this interface.

135
00:06:34,520 --> 00:06:37,420
We also actually want to see
if this access list is applied

136
00:06:37,420 --> 00:06:42,040
to gigabit 2 because router
5 has two interfaces that it

137
00:06:42,040 --> 00:06:43,670
could be talking on.

138
00:06:43,670 --> 00:06:45,400
But as we can see,
that access list

139
00:06:45,400 --> 00:06:48,530
is applied inbound on
this interface, as well.

140
00:06:48,530 --> 00:06:52,190
So this definitely
appears to be the problem.

141
00:06:52,190 --> 00:06:55,450
So it does appear that we
may have actually found

142
00:06:55,450 --> 00:06:57,170
an isolated the problem.

143
00:06:57,170 --> 00:07:00,530
So then the question always
comes up, how should we fix it?

144
00:07:00,530 --> 00:07:02,480
Well, what are our choices?

145
00:07:02,480 --> 00:07:06,460
Choice number one, we could
definitely just remove the ACL.

146
00:07:06,460 --> 00:07:08,560
That would certainly
solve the problem

147
00:07:08,560 --> 00:07:10,840
assuming the ACL is the problem.

148
00:07:10,840 --> 00:07:14,500
We could modify the
ACL to actually support

149
00:07:14,500 --> 00:07:18,920
BGP to allow that
traffic, or in this case,

150
00:07:18,920 --> 00:07:22,180
we could even just change
the direction of the ACL.

151
00:07:22,180 --> 00:07:24,730
It's applied inbound right now.

152
00:07:24,730 --> 00:07:27,940
If it was applied outbound,
it wouldn't filter

153
00:07:27,940 --> 00:07:29,710
the router's own traffic.

154
00:07:29,710 --> 00:07:32,770
But that would also probably
fundamentally change

155
00:07:32,770 --> 00:07:34,600
what the ACL is there for.

156
00:07:34,600 --> 00:07:38,330
So from a troubleshooting
and design perspective,

157
00:07:38,330 --> 00:07:40,930
I would look at this and
say, well, obviously,

158
00:07:40,930 --> 00:07:42,580
the ACL is there for a reason.

159
00:07:42,580 --> 00:07:43,930
Somebody wanted it there.

160
00:07:43,930 --> 00:07:46,570
It's supposed to be filtering
traffic in the direction

161
00:07:46,570 --> 00:07:48,100
that it's doing so.

162
00:07:48,100 --> 00:07:51,500
So the best fix, at
least I think so,

163
00:07:51,500 --> 00:07:56,540
would be to add BGP to the ACL
to allow it to come through.

164
00:07:56,540 --> 00:07:58,250
So that's what
we're going to do.

165
00:07:58,250 --> 00:08:01,163
Let's go ahead and
update that ACL.

166
00:08:01,163 --> 00:08:03,830
So first, let's just get a quick
reminder of what it looks like.

167
00:08:03,830 --> 00:08:05,770
So this is the current status.

168
00:08:05,770 --> 00:08:08,270
We'll go into
Configuration mode.

169
00:08:08,270 --> 00:08:10,090
We'll go into our access list.

170
00:08:10,090 --> 00:08:12,440
And then we'll create
a new statement.

171
00:08:12,440 --> 00:08:15,260
And it really doesn't matter
too much where we put this.

172
00:08:15,260 --> 00:08:17,540
However, it's a
routing protocol.

173
00:08:17,540 --> 00:08:19,310
I would generally
put it near the top.

174
00:08:19,310 --> 00:08:26,110
So we will say line 5 is going
to be to permit tcp from anyone

175
00:08:26,110 --> 00:08:30,130
to anyone if it equals bgp.

176
00:08:30,130 --> 00:08:33,789
Now, one downside to this
is if we do a show ip access

177
00:08:33,789 --> 00:08:38,260
list again, is now we have all
of our numbers nice and neat

178
00:08:38,260 --> 00:08:41,500
by tens except for
this 5 that we just

179
00:08:41,500 --> 00:08:43,640
had to stick at the top.

180
00:08:43,640 --> 00:08:46,090
So one cool feature we
can use if we want to,

181
00:08:46,090 --> 00:08:47,560
and this is, of
course, completely

182
00:08:47,560 --> 00:08:53,410
optional, we can say ip
access-list sequence,

183
00:08:53,410 --> 00:08:56,530
put in the name, and then
tell it what line number we

184
00:08:56,530 --> 00:08:58,160
want it to start with.

185
00:08:58,160 --> 00:09:00,520
So we'll say start
with 10, and then

186
00:09:00,520 --> 00:09:02,680
what number you want
it to increment by.

187
00:09:02,680 --> 00:09:04,420
We'll, again, say 10.

188
00:09:04,420 --> 00:09:08,150
And what this will do
is remember the list

189
00:09:08,150 --> 00:09:11,560
so that when we look at
it, it's now starting at 10

190
00:09:11,560 --> 00:09:13,690
and going through 70.

191
00:09:13,690 --> 00:09:18,040
By the way, also note
that our tcp any any

192
00:09:18,040 --> 00:09:23,470
equals bgp line line 10
already has 31 matches.

193
00:09:23,470 --> 00:09:24,850
I'm going to guess.

194
00:09:24,850 --> 00:09:28,070
That means our neighborships
are probably up.

195
00:09:28,070 --> 00:09:30,860
So let's do our show
ip bgp summary again,

196
00:09:30,860 --> 00:09:32,620
and we can see that
they've been up

197
00:09:32,620 --> 00:09:34,990
for about a minute and a
half, give or take here.

198
00:09:34,990 --> 00:09:37,550
And we've learned
eight prefixes.

199
00:09:37,550 --> 00:09:40,270
If we do a show ip
bgp, we're actually

200
00:09:40,270 --> 00:09:43,510
getting prefixes
coming from BGP.

201
00:09:43,510 --> 00:09:46,870
So this gives us verification
that we have, in fact,

202
00:09:46,870 --> 00:09:49,230
solved this ticket.

203
00:09:49,230 --> 00:09:53,630
So in this video, we had
a ticket involving BGP.

204
00:09:53,630 --> 00:09:55,700
But at the end of
the day, this one

205
00:09:55,700 --> 00:09:58,730
may not have actually been
directly related to BGP.

206
00:09:58,730 --> 00:10:01,850
It was just affecting
BGP traffic, therefore,

207
00:10:01,850 --> 00:10:04,050
preventing our neighborships
from coming up.

208
00:10:04,050 --> 00:10:07,190
But this is the kind of
thing we have to worry about,

209
00:10:07,190 --> 00:10:10,040
particularly with inbound ACLs.

210
00:10:10,040 --> 00:10:13,740
We have to make sure we
account for routing protocols.

211
00:10:13,740 --> 00:10:16,430
Now, one thing you
might note, and you

212
00:10:16,430 --> 00:10:18,870
may have to go back and
look at the ACL again,

213
00:10:18,870 --> 00:10:25,190
but it did not allow IS-IS,
which is actually our IGP here.

214
00:10:25,190 --> 00:10:30,620
Just a quick note on
that, IS-IS runs on CLNS.

215
00:10:30,620 --> 00:10:32,780
It doesn't run on IP.

216
00:10:32,780 --> 00:10:36,350
Therefore, an IP
access-list is not

217
00:10:36,350 --> 00:10:39,330
going to effect IS-IS traffic.

218
00:10:39,330 --> 00:10:41,940
That's why we didn't
have to allow it.

219
00:10:41,940 --> 00:10:45,390
But either way, this gets our
BGP neighbors up and running,

220
00:10:45,390 --> 00:10:48,350
and this solves this ticket.

221
00:10:48,350 --> 00:10:50,510
I hope this has been
informative for you,

222
00:10:50,510 --> 00:10:53,590
and I'd like to thank
you for viewing.

223
00:10:53,590 --> 00:10:57,000