[AUDIO LOGO]
So even though LDP is not a routing protocol,
it still forms neighborships as if it were.
The reason, of course, it does this
is much for the same reason routing protocols do.
It allows us to reliably exchange information
with our neighbors and, of course,
have information if those neighbors become unavailable.
Now, what's a little bit interesting
here is it actually uses sort of two different mechanisms.
And we'll see this as we jump into more detail.
But it uses hellos over UDP.
And it uses keepalives over TCP that
run at different intervals.
But we'll jump into all that detail.
And then we'll wrap up by looking at a Wireshark packet
capture of these packets on the wire
and take a look in more detail as what they look like.
So let's go ahead and jump in and get
started looking at the attributes of the neighborship.
So one of the first attributes of the LDP neighborship
that we need to discuss is the LDP router ID.
This is used to identify the neighbor and the label space
that that neighbor is using.
We'll talk more about that as we go through our discussion.
So first things first, the router ID really
should be manually configured.
This is much like we would want to do with an OSPF router
ID or a BGP router ID.
Will LDP automatically choose a router ID?
Yes, it will.
Should we let it do it automatically?
No, not usually.
Again, if you choose not to, if it's not configured,
it will choose the highest IP address
from a loopback interface.
If that sounds familiar, that's what a lot of routing protocols
do as well.
So it sort of follows that same process,
just like if no loopback exists, it will then use the highest IP
address from an interface.
Same basic idea, again following along almost exactly
with what OSPF does.
There is sort of a unique choice, however, on IOS XR
specifically.
You can actually configure a default global router ID.
And LDP can fall back and use that.
So it's an alternative.
But realistically, none of this should
matter, because you should be doing the router ID manually.
It's really just best practice.
So now shifting over and talking about the neighborship itself,
that neighborship is going to start.
Its first state is going to be discovery.
Step one is it's going to send a hello on the local segment.
So a few things about that hello--
first, it uses UDP.
It also uses the link local multicast
address 224.0.0.2, which is the reserved all routers link
local multicast address.
So it should hit every router on the segment.
All routers should be listening to that address.
Now, that doesn't necessarily mean
that they're listening to UDP port 646, which
is the port that this uses.
So all of the routers will receive this hello.
That doesn't necessarily mean all of the routers
are running LDP.
And this can contain a TLV, which
is a Type-Length-Value field, that
indicates a transport address.
That transport address is usually the router ID.
And it will be used for the unicast communication.
Now, these hellos are sent every 5 seconds.
We'll see this when we get to our Wireshark packet capture.
We can actually see the gap in the time frames between each
of these being 5 seconds.
And once we receive a valid hello,
we are then going to move to the adjacency phase.
So in the adjacency phase, we're now
going to open a TCP session between the devices.
This will be opened, or, you could say, initiated,
by the LSR that has the highest LDP router ID.
The session will be open either to the source
address of the packet, meaning the hello packet,
or to the transport address, assuming that the transport
address was sent in the hello.
The session is opened to TCP port 646.
So as you can see, we're using the same port on TCP
that we did on UDP.
After the TCP session is up, we are then
going to exchange initialization messages.
This is going to include things such as the label distribution
method, the session keepalive time,
and the fault-tolerant TLVs.
This will include information for session protection, which
we'll be talking about next.
After that, we will send the initial keepalive message.
The default is that we send this every 60 seconds.
So what we should see is for the UDP hellos,
those are going to be sent every 5 seconds.
Then once the TCP session comes up,
those keepalives will then be sent every 60 seconds.
And this is exactly what we'll see
in a few moments in our Wireshark packet capture.
So at this point, our LDP neighborship would be up.
Now, as we mentioned before, these adjacencies
can be established between nondirectly connected LSRs.
Of course, we can't use a link local multicast address
if they're not connected.
So instead, the LSR is going to have
to be configured to use unicast for the hello
rather than defaulting to the link local multicast.
This unicast session is referred to as a targeted hello
because it's being targeted, of course, to a specific unicast
address.
Beyond the fact that our UDP session--
therefore, our hellos-- will be using unicast,
the rest of this neighborship is going to be exactly
the same as usual.
In other words, we'll still form our TCP session.
That's still going to be unicast as it normally would be.
So this doesn't change anything apart
from the original UDP multicast now being unicast.
So now let's go ahead and bring up Wireshark and take a look
at these packets.
So let's start here by looking at these LDP packets.
These are the UDP hellos.
And as we can see, they're sourced from alternating
between router 1 and router 3.
That's where I performed this capture.
Notice, however, they're always going
to the destination of the multicast address,
the 224.0.0.2.
If we look down here in our decoding window,
we can see that this is in fact UDP.
And it's using both the source and destination port of 646.
Now, we could go ahead and open up
the LDP section of this decode.
We'll see there's not a whole ton in here.
We do see the LSR router ID, of course.
And we see the current label space.
We'll be talking more about label spaces a bit later.
But as we can see, by default, it's using label space 0.
We also see that the Hello Message is expandable.
Under the Hello Message, we see that there's not
a whole lot going on here, except we
do have these Common Hello Parameters, the IPv4 Transport
Address, and any vendor private TLVs.
If we open up the IPv4 Transport Address,
we can see right here where it is exchanging
that IPv4 transport address.
And it is in fact using its router ID.
So that's the overall structure of the hello message.
If we go back up to our packet window,
let's also be sure to take note on these packets
that they're going every 5 seconds.
We can see that packets 1 and 2 are
pretty much at the zero second.
We see packets 3 and 4 right around 5 seconds, packets 5
and 6 right around 10 seconds.
And again, we're seeing them in pairs
because it's each router sending the hellos to each other.
Now, if we scroll down a bit in this window,
if we get down here, say, to packet 23,
we can see now we have a unicast message going from router 1
to router 3.
That's listed as a Keep Alive Message.
So let's go ahead and highlight that packet.
And notice in our packet decoding, this is a TCP packet.
Its source port is the 646, although it is using
a random destination port.
Once again, we have an LDP section.
Let's go ahead and expand that.
It's exchanging its LSR router ID as well as the label space.
And it's listed as just a simple Keep Alive Message.
If we go back up to our packet window now,
keep in mind that this packet came
in at right around 49 seconds into our packet capture.
This is going from router 1 to router 3.
If we scroll down more, we see here another keepalive
going from router 1 to router 3 at right around 105 seconds.
If you subtract the 49 from this,
these keepalives are right around 56 seconds apart,
give or take.
So this is right around the 60-second mark, where we should
be seeing these keepalives.
So what we're seeing is, as we predicted,
hellos being sent every 5 seconds
and keepalives being sent every 60.
In this video, we looked at more detail
on how the LDP neighborships get formed,
how they use UDP versus TCP, and the different phases they go
through in their neighborships.
Now, one of the problems we might have
is, what if a single link between devices
fail and therefore we lose our LDP neighborships and then
all of the labels?
Well, we can do something about that.
It's called session protection.
And that's exactly what we get to look at next.
In the meantime, I hope this has been informative for you,
and I'd like to thank you for viewing.