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

2
00:00:03,784 --> 00:00:08,050

3
00:00:08,050 --> 00:00:11,680
So even though LDP is
not a routing protocol,

4
00:00:11,680 --> 00:00:16,000
it still forms
neighborships as if it were.

5
00:00:16,000 --> 00:00:17,710
The reason, of
course, it does this

6
00:00:17,710 --> 00:00:21,050
is much for the same reason
routing protocols do.

7
00:00:21,050 --> 00:00:24,760
It allows us to reliably
exchange information

8
00:00:24,760 --> 00:00:27,320
with our neighbors
and, of course,

9
00:00:27,320 --> 00:00:31,120
have information if those
neighbors become unavailable.

10
00:00:31,120 --> 00:00:32,890
Now, what's a little
bit interesting

11
00:00:32,890 --> 00:00:36,580
here is it actually uses sort
of two different mechanisms.

12
00:00:36,580 --> 00:00:39,590
And we'll see this as we
jump into more detail.

13
00:00:39,590 --> 00:00:43,270
But it uses hellos over UDP.

14
00:00:43,270 --> 00:00:47,470
And it uses keepalives
over TCP that

15
00:00:47,470 --> 00:00:49,090
run at different intervals.

16
00:00:49,090 --> 00:00:52,120
But we'll jump into
all that detail.

17
00:00:52,120 --> 00:00:56,230
And then we'll wrap up by
looking at a Wireshark packet

18
00:00:56,230 --> 00:00:59,170
capture of these
packets on the wire

19
00:00:59,170 --> 00:01:03,200
and take a look in more
detail as what they look like.

20
00:01:03,200 --> 00:01:05,170
So let's go ahead
and jump in and get

21
00:01:05,170 --> 00:01:10,070
started looking at the
attributes of the neighborship.

22
00:01:10,070 --> 00:01:13,040
So one of the first attributes
of the LDP neighborship

23
00:01:13,040 --> 00:01:17,780
that we need to discuss
is the LDP router ID.

24
00:01:17,780 --> 00:01:22,655
This is used to identify the
neighbor and the label space

25
00:01:22,655 --> 00:01:24,770
that that neighbor is using.

26
00:01:24,770 --> 00:01:28,500
We'll talk more about that as
we go through our discussion.

27
00:01:28,500 --> 00:01:32,690
So first things first,
the router ID really

28
00:01:32,690 --> 00:01:34,880
should be manually configured.

29
00:01:34,880 --> 00:01:38,390
This is much like we would
want to do with an OSPF router

30
00:01:38,390 --> 00:01:41,720
ID or a BGP router ID.

31
00:01:41,720 --> 00:01:44,990
Will LDP automatically
choose a router ID?

32
00:01:44,990 --> 00:01:46,040
Yes, it will.

33
00:01:46,040 --> 00:01:48,140
Should we let it do
it automatically?

34
00:01:48,140 --> 00:01:50,240
No, not usually.

35
00:01:50,240 --> 00:01:54,200
Again, if you choose not
to, if it's not configured,

36
00:01:54,200 --> 00:01:56,960
it will choose the
highest IP address

37
00:01:56,960 --> 00:01:59,240
from a loopback interface.

38
00:01:59,240 --> 00:02:02,660
If that sounds familiar, that's
what a lot of routing protocols

39
00:02:02,660 --> 00:02:03,870
do as well.

40
00:02:03,870 --> 00:02:06,530
So it sort of follows
that same process,

41
00:02:06,530 --> 00:02:11,960
just like if no loopback exists,
it will then use the highest IP

42
00:02:11,960 --> 00:02:14,360
address from an interface.

43
00:02:14,360 --> 00:02:18,890
Same basic idea, again
following along almost exactly

44
00:02:18,890 --> 00:02:21,440
with what OSPF does.

45
00:02:21,440 --> 00:02:25,610
There is sort of a unique
choice, however, on IOS XR

46
00:02:25,610 --> 00:02:26,810
specifically.

47
00:02:26,810 --> 00:02:32,210
You can actually configure
a default global router ID.

48
00:02:32,210 --> 00:02:35,430
And LDP can fall
back and use that.

49
00:02:35,430 --> 00:02:37,130
So it's an alternative.

50
00:02:37,130 --> 00:02:39,620
But realistically,
none of this should

51
00:02:39,620 --> 00:02:44,660
matter, because you should be
doing the router ID manually.

52
00:02:44,660 --> 00:02:48,360
It's really just best practice.

53
00:02:48,360 --> 00:02:51,980
So now shifting over and talking
about the neighborship itself,

54
00:02:51,980 --> 00:02:54,440
that neighborship
is going to start.

55
00:02:54,440 --> 00:02:58,220
Its first state is
going to be discovery.

56
00:02:58,220 --> 00:03:02,700
Step one is it's going to send
a hello on the local segment.

57
00:03:02,700 --> 00:03:05,090
So a few things
about that hello--

58
00:03:05,090 --> 00:03:08,420
first, it uses UDP.

59
00:03:08,420 --> 00:03:11,900
It also uses the
link local multicast

60
00:03:11,900 --> 00:03:19,310
address 224.0.0.2, which is
the reserved all routers link

61
00:03:19,310 --> 00:03:21,390
local multicast address.

62
00:03:21,390 --> 00:03:24,470
So it should hit every
router on the segment.

63
00:03:24,470 --> 00:03:28,440
All routers should be
listening to that address.

64
00:03:28,440 --> 00:03:30,740
Now, that doesn't
necessarily mean

65
00:03:30,740 --> 00:03:35,900
that they're listening
to UDP port 646, which

66
00:03:35,900 --> 00:03:37,620
is the port that this uses.

67
00:03:37,620 --> 00:03:40,160
So all of the routers
will receive this hello.

68
00:03:40,160 --> 00:03:42,650
That doesn't necessarily
mean all of the routers

69
00:03:42,650 --> 00:03:44,660
are running LDP.

70
00:03:44,660 --> 00:03:47,210
And this can
contain a TLV, which

71
00:03:47,210 --> 00:03:49,610
is a Type-Length-Value
field, that

72
00:03:49,610 --> 00:03:52,160
indicates a transport address.

73
00:03:52,160 --> 00:03:56,210
That transport address
is usually the router ID.

74
00:03:56,210 --> 00:04:00,630
And it will be used for
the unicast communication.

75
00:04:00,630 --> 00:04:04,340
Now, these hellos are
sent every 5 seconds.

76
00:04:04,340 --> 00:04:08,520
We'll see this when we get to
our Wireshark packet capture.

77
00:04:08,520 --> 00:04:11,480
We can actually see the gap in
the time frames between each

78
00:04:11,480 --> 00:04:14,180
of these being 5 seconds.

79
00:04:14,180 --> 00:04:17,240
And once we receive
a valid hello,

80
00:04:17,240 --> 00:04:22,650
we are then going to move
to the adjacency phase.

81
00:04:22,650 --> 00:04:24,860
So in the adjacency
phase, we're now

82
00:04:24,860 --> 00:04:29,820
going to open a TCP session
between the devices.

83
00:04:29,820 --> 00:04:33,230
This will be opened, or,
you could say, initiated,

84
00:04:33,230 --> 00:04:38,700
by the LSR that has the
highest LDP router ID.

85
00:04:38,700 --> 00:04:41,510
The session will be open
either to the source

86
00:04:41,510 --> 00:04:45,920
address of the packet,
meaning the hello packet,

87
00:04:45,920 --> 00:04:50,210
or to the transport address,
assuming that the transport

88
00:04:50,210 --> 00:04:53,900
address was sent in the hello.

89
00:04:53,900 --> 00:04:58,190
The session is opened
to TCP port 646.

90
00:04:58,190 --> 00:05:01,910
So as you can see, we're
using the same port on TCP

91
00:05:01,910 --> 00:05:04,400
that we did on UDP.

92
00:05:04,400 --> 00:05:07,430
After the TCP session
is up, we are then

93
00:05:07,430 --> 00:05:10,940
going to exchange
initialization messages.

94
00:05:10,940 --> 00:05:14,330
This is going to include things
such as the label distribution

95
00:05:14,330 --> 00:05:17,990
method, the session
keepalive time,

96
00:05:17,990 --> 00:05:21,770
and the fault-tolerant TLVs.

97
00:05:21,770 --> 00:05:25,400
This will include information
for session protection, which

98
00:05:25,400 --> 00:05:27,440
we'll be talking about next.

99
00:05:27,440 --> 00:05:31,640
After that, we will send the
initial keepalive message.

100
00:05:31,640 --> 00:05:37,000
The default is that we
send this every 60 seconds.

101
00:05:37,000 --> 00:05:41,490
So what we should see
is for the UDP hellos,

102
00:05:41,490 --> 00:05:44,610
those are going to be
sent every 5 seconds.

103
00:05:44,610 --> 00:05:47,550
Then once the TCP
session comes up,

104
00:05:47,550 --> 00:05:51,870
those keepalives will then
be sent every 60 seconds.

105
00:05:51,870 --> 00:05:54,270
And this is exactly
what we'll see

106
00:05:54,270 --> 00:05:58,330
in a few moments in our
Wireshark packet capture.

107
00:05:58,330 --> 00:06:02,670
So at this point, our LDP
neighborship would be up.

108
00:06:02,670 --> 00:06:06,090
Now, as we mentioned
before, these adjacencies

109
00:06:06,090 --> 00:06:12,120
can be established between
nondirectly connected LSRs.

110
00:06:12,120 --> 00:06:16,680
Of course, we can't use a
link local multicast address

111
00:06:16,680 --> 00:06:19,030
if they're not connected.

112
00:06:19,030 --> 00:06:22,050
So instead, the LSR
is going to have

113
00:06:22,050 --> 00:06:26,400
to be configured to use
unicast for the hello

114
00:06:26,400 --> 00:06:30,360
rather than defaulting to
the link local multicast.

115
00:06:30,360 --> 00:06:36,240
This unicast session is
referred to as a targeted hello

116
00:06:36,240 --> 00:06:40,080
because it's being targeted, of
course, to a specific unicast

117
00:06:40,080 --> 00:06:41,460
address.

118
00:06:41,460 --> 00:06:44,220
Beyond the fact that
our UDP session--

119
00:06:44,220 --> 00:06:48,150
therefore, our hellos--
will be using unicast,

120
00:06:48,150 --> 00:06:52,020
the rest of this neighborship
is going to be exactly

121
00:06:52,020 --> 00:06:53,850
the same as usual.

122
00:06:53,850 --> 00:06:56,700
In other words, we'll
still form our TCP session.

123
00:06:56,700 --> 00:06:59,910
That's still going to be
unicast as it normally would be.

124
00:06:59,910 --> 00:07:02,730
So this doesn't
change anything apart

125
00:07:02,730 --> 00:07:08,370
from the original UDP
multicast now being unicast.

126
00:07:08,370 --> 00:07:12,090
So now let's go ahead and bring
up Wireshark and take a look

127
00:07:12,090 --> 00:07:13,750
at these packets.

128
00:07:13,750 --> 00:07:17,820
So let's start here by
looking at these LDP packets.

129
00:07:17,820 --> 00:07:20,850
These are the UDP hellos.

130
00:07:20,850 --> 00:07:24,510
And as we can see, they're
sourced from alternating

131
00:07:24,510 --> 00:07:27,380
between router 1 and router 3.

132
00:07:27,380 --> 00:07:29,670
That's where I
performed this capture.

133
00:07:29,670 --> 00:07:31,470
Notice, however,
they're always going

134
00:07:31,470 --> 00:07:34,680
to the destination of
the multicast address,

135
00:07:34,680 --> 00:07:38,910
the 224.0.0.2.

136
00:07:38,910 --> 00:07:41,950
If we look down here
in our decoding window,

137
00:07:41,950 --> 00:07:45,540
we can see that
this is in fact UDP.

138
00:07:45,540 --> 00:07:51,270
And it's using both the source
and destination port of 646.

139
00:07:51,270 --> 00:07:53,310
Now, we could go
ahead and open up

140
00:07:53,310 --> 00:07:56,730
the LDP section of this decode.

141
00:07:56,730 --> 00:07:59,430
We'll see there's not
a whole ton in here.

142
00:07:59,430 --> 00:08:02,880
We do see the LSR
router ID, of course.

143
00:08:02,880 --> 00:08:05,730
And we see the
current label space.

144
00:08:05,730 --> 00:08:09,670
We'll be talking more about
label spaces a bit later.

145
00:08:09,670 --> 00:08:14,400
But as we can see, by default,
it's using label space 0.

146
00:08:14,400 --> 00:08:18,390
We also see that the Hello
Message is expandable.

147
00:08:18,390 --> 00:08:21,090
Under the Hello Message,
we see that there's not

148
00:08:21,090 --> 00:08:23,880
a whole lot going
on here, except we

149
00:08:23,880 --> 00:08:28,080
do have these Common Hello
Parameters, the IPv4 Transport

150
00:08:28,080 --> 00:08:32,730
Address, and any
vendor private TLVs.

151
00:08:32,730 --> 00:08:36,480
If we open up the IPv4
Transport Address,

152
00:08:36,480 --> 00:08:39,330
we can see right here
where it is exchanging

153
00:08:39,330 --> 00:08:41,820
that IPv4 transport address.

154
00:08:41,820 --> 00:08:46,030
And it is in fact
using its router ID.

155
00:08:46,030 --> 00:08:49,080
So that's the overall
structure of the hello message.

156
00:08:49,080 --> 00:08:52,500
If we go back up to
our packet window,

157
00:08:52,500 --> 00:08:55,620
let's also be sure to
take note on these packets

158
00:08:55,620 --> 00:08:58,690
that they're going
every 5 seconds.

159
00:08:58,690 --> 00:09:00,960
We can see that
packets 1 and 2 are

160
00:09:00,960 --> 00:09:03,210
pretty much at the zero second.

161
00:09:03,210 --> 00:09:07,650
We see packets 3 and 4 right
around 5 seconds, packets 5

162
00:09:07,650 --> 00:09:09,610
and 6 right around 10 seconds.

163
00:09:09,610 --> 00:09:11,220
And again, we're
seeing them in pairs

164
00:09:11,220 --> 00:09:15,720
because it's each router sending
the hellos to each other.

165
00:09:15,720 --> 00:09:18,710
Now, if we scroll down
a bit in this window,

166
00:09:18,710 --> 00:09:21,800
if we get down here,
say, to packet 23,

167
00:09:21,800 --> 00:09:28,130
we can see now we have a unicast
message going from router 1

168
00:09:28,130 --> 00:09:29,750
to router 3.

169
00:09:29,750 --> 00:09:33,060
That's listed as a
Keep Alive Message.

170
00:09:33,060 --> 00:09:37,020
So let's go ahead and
highlight that packet.

171
00:09:37,020 --> 00:09:42,030
And notice in our packet
decoding, this is a TCP packet.

172
00:09:42,030 --> 00:09:46,350
Its source port is the
646, although it is using

173
00:09:46,350 --> 00:09:48,600
a random destination port.

174
00:09:48,600 --> 00:09:51,160
Once again, we have
an LDP section.

175
00:09:51,160 --> 00:09:52,950
Let's go ahead and expand that.

176
00:09:52,950 --> 00:09:57,900
It's exchanging its LSR router
ID as well as the label space.

177
00:09:57,900 --> 00:10:01,920
And it's listed as just a
simple Keep Alive Message.

178
00:10:01,920 --> 00:10:05,010
If we go back up to
our packet window now,

179
00:10:05,010 --> 00:10:07,650
keep in mind that
this packet came

180
00:10:07,650 --> 00:10:12,720
in at right around 49 seconds
into our packet capture.

181
00:10:12,720 --> 00:10:16,140
This is going from
router 1 to router 3.

182
00:10:16,140 --> 00:10:20,730
If we scroll down more, we
see here another keepalive

183
00:10:20,730 --> 00:10:26,700
going from router 1 to router
3 at right around 105 seconds.

184
00:10:26,700 --> 00:10:29,340
If you subtract
the 49 from this,

185
00:10:29,340 --> 00:10:33,360
these keepalives are right
around 56 seconds apart,

186
00:10:33,360 --> 00:10:34,660
give or take.

187
00:10:34,660 --> 00:10:38,460
So this is right around the
60-second mark, where we should

188
00:10:38,460 --> 00:10:40,500
be seeing these keepalives.

189
00:10:40,500 --> 00:10:43,440
So what we're seeing
is, as we predicted,

190
00:10:43,440 --> 00:10:46,140
hellos being sent
every 5 seconds

191
00:10:46,140 --> 00:10:51,070
and keepalives
being sent every 60.

192
00:10:51,070 --> 00:10:54,490
In this video, we
looked at more detail

193
00:10:54,490 --> 00:10:58,220
on how the LDP
neighborships get formed,

194
00:10:58,220 --> 00:11:03,700
how they use UDP versus TCP,
and the different phases they go

195
00:11:03,700 --> 00:11:06,130
through in their neighborships.

196
00:11:06,130 --> 00:11:08,950
Now, one of the
problems we might have

197
00:11:08,950 --> 00:11:12,310
is, what if a single
link between devices

198
00:11:12,310 --> 00:11:16,780
fail and therefore we lose
our LDP neighborships and then

199
00:11:16,780 --> 00:11:18,310
all of the labels?

200
00:11:18,310 --> 00:11:20,930
Well, we can do
something about that.

201
00:11:20,930 --> 00:11:22,900
It's called session protection.

202
00:11:22,900 --> 00:11:25,750
And that's exactly what
we get to look at next.

203
00:11:25,750 --> 00:11:29,440
In the meantime, I hope this
has been informative for you,

204
00:11:29,440 --> 00:11:32,550
and I'd like to thank
you for viewing.

205
00:11:32,550 --> 00:11:36,000