1
00:00:00,000 --> 00:00:02,928
[MUSIC PLAYING]

2
00:00:02,928 --> 00:00:12,210

3
00:00:12,210 --> 00:00:15,420
Moving on now to
Trouble Ticket 4.

4
00:00:15,420 --> 00:00:19,020
This one is about R2 and R9.

5
00:00:19,020 --> 00:00:23,320
So it's saying that R2 and R9
are supposed to be neighbors,

6
00:00:23,320 --> 00:00:25,590
but they are currently down.

7
00:00:25,590 --> 00:00:29,220
So as per usual, let's jump
over to the command line

8
00:00:29,220 --> 00:00:33,430
and see what's going on
with this neighborship.

9
00:00:33,430 --> 00:00:37,330
So we'll start here on Router
2 with our typical show IP BGP

10
00:00:37,330 --> 00:00:38,320
summary--

11
00:00:38,320 --> 00:00:41,710
great command to start with
when we're troubleshooting BGP.

12
00:00:41,710 --> 00:00:48,610
And what we see is we have this
50.1.29.9, which is currently

13
00:00:48,610 --> 00:00:50,290
in an active state.

14
00:00:50,290 --> 00:00:53,470
Now, since it's
active, that tells us

15
00:00:53,470 --> 00:00:56,530
that we have a route
to it, which we should,

16
00:00:56,530 --> 00:00:59,230
because it's a directly
connected interface.

17
00:00:59,230 --> 00:01:03,250
But let's verify that we
actually have a connection,

18
00:01:03,250 --> 00:01:04,930
and that it's working.

19
00:01:04,930 --> 00:01:07,040
Let's go ahead and
ping that neighbor.

20
00:01:07,040 --> 00:01:10,120
So 50.1.29.9.

21
00:01:10,120 --> 00:01:12,770
If we ping it, we can see
that that's successful.

22
00:01:12,770 --> 00:01:15,380
So it appears to be working.

23
00:01:15,380 --> 00:01:17,440
So just at first
glance here, this

24
00:01:17,440 --> 00:01:19,580
appears to be working properly.

25
00:01:19,580 --> 00:01:22,660
Let's go see what's
going on on Router 9.

26
00:01:22,660 --> 00:01:26,450
Once again, let's do
our show IP BGP summary.

27
00:01:26,450 --> 00:01:30,100
And what's interesting about
this output is we can see that

28
00:01:30,100 --> 00:01:35,980
we have a BGP peer
group, PG_AS100_Peers,

29
00:01:35,980 --> 00:01:43,120
that looks like it's tied to
a listen range of 50.1.0.0/16.

30
00:01:43,120 --> 00:01:46,750
Also, it has no neighbors
in that listen range

31
00:01:46,750 --> 00:01:48,830
because nothing's listed here.

32
00:01:48,830 --> 00:01:52,540
So if we do a show
run section BGP,

33
00:01:52,540 --> 00:01:54,940
we can see pretty much
what we suspected.

34
00:01:54,940 --> 00:01:58,750
Here we have our listen range,
which matches what our show IP

35
00:01:58,750 --> 00:02:00,640
BGP summary showed us.

36
00:02:00,640 --> 00:02:03,280
It is in fact tied
to that peer group.

37
00:02:03,280 --> 00:02:04,990
The peer group does exist.

38
00:02:04,990 --> 00:02:06,580
It's been configured.

39
00:02:06,580 --> 00:02:08,740
It's got the remote
AS configured.

40
00:02:08,740 --> 00:02:10,840
It's got a password configured.

41
00:02:10,840 --> 00:02:13,700
And it's originating
a default route.

42
00:02:13,700 --> 00:02:15,322
Now, originating
the default route

43
00:02:15,322 --> 00:02:17,530
is not going to have anything
to do with this ticket.

44
00:02:17,530 --> 00:02:19,550
The remote AS is correct.

45
00:02:19,550 --> 00:02:23,440
But let's keep in mind that
there's a password set here.

46
00:02:23,440 --> 00:02:25,720
Maybe that is going
to become important.

47
00:02:25,720 --> 00:02:27,730
Always good things to know.

48
00:02:27,730 --> 00:02:30,460
It's also not
necessarily a bad idea,

49
00:02:30,460 --> 00:02:33,190
depending on your
terminal software,

50
00:02:33,190 --> 00:02:35,860
go ahead and highlight
that password,

51
00:02:35,860 --> 00:02:39,130
and just make sure
there's no extra spaces

52
00:02:39,130 --> 00:02:41,680
or anything like that,
that we can't easily

53
00:02:41,680 --> 00:02:44,170
see right on the text output.

54
00:02:44,170 --> 00:02:47,480
In this case, of course,
it appears to be fine.

55
00:02:47,480 --> 00:02:50,470
So like always, when
things generally look OK,

56
00:02:50,470 --> 00:02:53,530
never a bad idea to
fire up Wireshark

57
00:02:53,530 --> 00:02:56,540
and see what these packets
look like on the wire.

58
00:02:56,540 --> 00:02:58,670
So let's do just that.

59
00:02:58,670 --> 00:03:00,760
So here's our Wireshark capture.

60
00:03:00,760 --> 00:03:05,140
It is filtered to
match on TCP or BGP.

61
00:03:05,140 --> 00:03:08,830
Notice that the very first
packet that we captured here

62
00:03:08,830 --> 00:03:11,860
is a TCP send request.

63
00:03:11,860 --> 00:03:16,240
But notice that it's going
from the source of 10.2.2.2

64
00:03:16,240 --> 00:03:19,720
to 50.1.29.9.

65
00:03:19,720 --> 00:03:22,840
So it's going from
Router 2 to Router 9,

66
00:03:22,840 --> 00:03:27,960
but it's being sourced
from Router 2's loopback.

67
00:03:27,960 --> 00:03:32,220
The reason that's a problem
is, remember the listen range

68
00:03:32,220 --> 00:03:35,070
that we just saw on Router 9.

69
00:03:35,070 --> 00:03:38,610
Router 9 is configured
for a listen range

70
00:03:38,610 --> 00:03:43,680
that matches the physical
interfaces, not the loopbacks.

71
00:03:43,680 --> 00:03:46,590
Plus, Router 9 may
not even have a route

72
00:03:46,590 --> 00:03:49,080
back to Router 2's loopback.

73
00:03:49,080 --> 00:03:52,650
We're not running
an IGP with Router 9

74
00:03:52,650 --> 00:03:54,520
in this lab environment.

75
00:03:54,520 --> 00:03:58,510
So for a couple of reasons,
that could be problematic.

76
00:03:58,510 --> 00:04:02,250
And we see that because of this,
we're never even completing

77
00:04:02,250 --> 00:04:04,410
the TCP three-way handshake.

78
00:04:04,410 --> 00:04:06,420
It's sending the send request.

79
00:04:06,420 --> 00:04:08,580
And then what do
we see after this?

80
00:04:08,580 --> 00:04:12,930
Just retransmission
timeouts as it keeps trying,

81
00:04:12,930 --> 00:04:15,150
but it's not getting anywhere.

82
00:04:15,150 --> 00:04:17,940
Now, one interesting thing we
could check while we're here

83
00:04:17,940 --> 00:04:21,600
though, is since we
know there's a password,

84
00:04:21,600 --> 00:04:23,880
we could check if
Router 2 is at least

85
00:04:23,880 --> 00:04:25,710
trying to send that password.

86
00:04:25,710 --> 00:04:28,060
Let's see if we can see it here.

87
00:04:28,060 --> 00:04:32,260
So if we open up TCP,
and then we scroll down,

88
00:04:32,260 --> 00:04:35,280
then we open Options,
we can actually

89
00:04:35,280 --> 00:04:39,540
see right here that the
TCP MD5 signature is

90
00:04:39,540 --> 00:04:42,100
attached to these packets.

91
00:04:42,100 --> 00:04:44,140
So what does all this tell us?

92
00:04:44,140 --> 00:04:46,950
It tells us that Router
2 looks like it's

93
00:04:46,950 --> 00:04:48,600
configured for a password.

94
00:04:48,600 --> 00:04:50,880
Now, let's not kid ourselves.

95
00:04:50,880 --> 00:04:54,330
That password could, of course,
still be the wrong password.

96
00:04:54,330 --> 00:04:57,460
Nobody says that password
is actually correct.

97
00:04:57,460 --> 00:05:02,490
But it is setting an MD5
password in option 19,

98
00:05:02,490 --> 00:05:04,380
like it's supposed to.

99
00:05:04,380 --> 00:05:08,490
It's just sourcing the packet
from its loopback instead

100
00:05:08,490 --> 00:05:10,420
of its physical interface.

101
00:05:10,420 --> 00:05:12,150
So let's jump over
and take a look

102
00:05:12,150 --> 00:05:14,400
at that configuration
on Router 2.

103
00:05:14,400 --> 00:05:18,430
And I'm betting that's
what we're going to see.

104
00:05:18,430 --> 00:05:21,690
So if we do our
show run router BGP,

105
00:05:21,690 --> 00:05:25,680
and we look here at
our neighbor 50.1.29.9,

106
00:05:25,680 --> 00:05:28,800
we see exactly
what we suspected.

107
00:05:28,800 --> 00:05:31,300
First, yes, it has a password.

108
00:05:31,300 --> 00:05:33,340
Of course, it's
shown encrypted here.

109
00:05:33,340 --> 00:05:36,690
So we can't easily tell if
it's the correct password.

110
00:05:36,690 --> 00:05:40,230
If we weren't sure, we could
just try to put it in again.

111
00:05:40,230 --> 00:05:45,150
But more importantly, we see
this update source loopback 0.

112
00:05:45,150 --> 00:05:47,840
That should not be there.

113
00:05:47,840 --> 00:05:50,260
So it does appear
that we have found

114
00:05:50,260 --> 00:05:53,020
the issue here on Router 2.

115
00:05:53,020 --> 00:05:56,540
As usual, we have to
decide how to fix it.

116
00:05:56,540 --> 00:05:59,590
So there's really two
choices in this case,

117
00:05:59,590 --> 00:06:01,990
that are relatively easy.

118
00:06:01,990 --> 00:06:05,230
One of them would
be to simply change

119
00:06:05,230 --> 00:06:08,950
the listen range on
Router 9, and actually

120
00:06:08,950 --> 00:06:11,020
peer up using the loopback.

121
00:06:11,020 --> 00:06:14,230
We've already discussed the
problem with that though.

122
00:06:14,230 --> 00:06:19,130
Router 9 doesn't have a route
back to Router 2's loopback.

123
00:06:19,130 --> 00:06:21,470
So, yes, we could
do it that way,

124
00:06:21,470 --> 00:06:24,670
but then we'd have to configure
something like static routing,

125
00:06:24,670 --> 00:06:29,380
or fire up an IGP, maybe bring
Router 9 into our existing

126
00:06:29,380 --> 00:06:31,300
IS-IS routing domain.

127
00:06:31,300 --> 00:06:35,050
We would have to do something
to allow that to work.

128
00:06:35,050 --> 00:06:38,230
Or, optionally, we
could just pair these up

129
00:06:38,230 --> 00:06:40,360
on their physical
interfaces, which

130
00:06:40,360 --> 00:06:43,420
given this neighbor
statement here on Router 2,

131
00:06:43,420 --> 00:06:46,150
and the listen
range on Router 9,

132
00:06:46,150 --> 00:06:49,810
it sort of looks like that's
how this was intended to work.

133
00:06:49,810 --> 00:06:52,030
These look like they
were intended to work

134
00:06:52,030 --> 00:06:54,170
on their physical interfaces.

135
00:06:54,170 --> 00:06:57,940
So in that case, I think we
should just take out the update

136
00:06:57,940 --> 00:07:01,150
source loopback 0 on Router 2.

137
00:07:01,150 --> 00:07:03,380
That's probably
our best solution.

138
00:07:03,380 --> 00:07:05,820
So let's do that.

139
00:07:05,820 --> 00:07:09,380
We'll simply go into
configuration, into router BGP

140
00:07:09,380 --> 00:07:17,960
100, into neighbor 50.1.29.9,
and say no update source

141
00:07:17,960 --> 00:07:19,700
loopback 0.

142
00:07:19,700 --> 00:07:23,970
We'll commit that change
and our configuration.

143
00:07:23,970 --> 00:07:26,510
And if we give it just a
moment, that neighborship

144
00:07:26,510 --> 00:07:27,990
should come up.

145
00:07:27,990 --> 00:07:29,750
So I gave it a few
seconds, let's check.

146
00:07:29,750 --> 00:07:32,640
Show IP BGP summary.

147
00:07:32,640 --> 00:07:36,710
And we can see that Router
9 is now up properly.

148
00:07:36,710 --> 00:07:39,500
It's been up for 41 seconds.

149
00:07:39,500 --> 00:07:42,560
Let's, of course, verify this
on the Router 9 side as well.

150
00:07:42,560 --> 00:07:45,150
Although, I'm sure
it will agree.

151
00:07:45,150 --> 00:07:47,850
So again, show IP BGP summary.

152
00:07:47,850 --> 00:07:53,570
And we in fact see that
50.1.29.2 is in fact up.

153
00:07:53,570 --> 00:07:55,760
It's been up for a
minute and 2 seconds.

154
00:07:55,760 --> 00:07:58,250
We've received eight
prefixes from it.

155
00:07:58,250 --> 00:08:01,460
And notice the asterisk
on the front of this,

156
00:08:01,460 --> 00:08:06,230
that it's learned through a
dynamic listen range, which

157
00:08:06,230 --> 00:08:12,650
also means that it's a member of
our peer group PG_AS100_Peers.

158
00:08:12,650 --> 00:08:16,040
So now that it's up and
running, if we do a show IP BGP,

159
00:08:16,040 --> 00:08:19,160
we should see that we are,
in fact, getting prefixes,

160
00:08:19,160 --> 00:08:22,430
and we're injecting
a default. We

161
00:08:22,430 --> 00:08:25,700
could also verify that that
default is showing up properly

162
00:08:25,700 --> 00:08:28,010
on Router 2, just to
make sure we're fully

163
00:08:28,010 --> 00:08:29,730
exchanging prefixes.

164
00:08:29,730 --> 00:08:31,970
So let's do a show IP BGP here.

165
00:08:31,970 --> 00:08:35,360
And we see, in fact, that we do
have that default route that's

166
00:08:35,360 --> 00:08:37,940
being sent from Router 9.

167
00:08:37,940 --> 00:08:41,659
So with the neighbors up and
the prefixes being exchanged,

168
00:08:41,659 --> 00:08:46,630
that's pretty good proof that
we have solved this ticket.

169
00:08:46,630 --> 00:08:50,880
So in this video, we saw a
problem pretty much directly

170
00:08:50,880 --> 00:08:55,320
related to one of our routers
having the incorrect source

171
00:08:55,320 --> 00:08:59,530
address configured to
send its BGP connections.

172
00:08:59,530 --> 00:09:03,940
Now, update source loopback 0
isn't a bad command, of course,

173
00:09:03,940 --> 00:09:06,780
if you're actually trying
to peer with loopbacks.

174
00:09:06,780 --> 00:09:09,330
But in this particular
case, we weren't.

175
00:09:09,330 --> 00:09:13,620
One router was configured to
peer with physical addresses,

176
00:09:13,620 --> 00:09:16,320
the other one was set
to peer with loopback.

177
00:09:16,320 --> 00:09:20,040
And of course, it really doesn't
matter which one we choose,

178
00:09:20,040 --> 00:09:22,620
as long as we have the
underlying routing.

179
00:09:22,620 --> 00:09:26,610
It's just that both
sides do need to agree.

180
00:09:26,610 --> 00:09:28,770
I hope this has been
informative for you,

181
00:09:28,770 --> 00:09:31,790
and I'd like to thank
you for viewing.

182
00:09:31,790 --> 00:09:35,000