All right, so here's the problem.
You've got two neighbors.
They both have local labels for a single network.
They're both advertising those labels to us.
As far as making a forwarding decision, which way do we go?
This way, or this way?
In this video, we're going to demystify how that choice is
made, and made correctly.
So in this demonstration about choosing the best
path, or which label to use, and which direction to send it,
I'm going to use the existing lab that we
had in the previous video, because it's already WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
had in the previous video, because it's already
got the MPLS enabled on it, and we've also
constrained the ranges.
We can tell where the labels are coming from.
And so let's focus on one route.
So in our topology, let's focus on this bad boy right here.
Let's focus on the network 4.4.4.4,
and let's go to R2's perspective,
because R3 is advertising that, hey, I've
got a local label for 4.4.4.4.
R1's advertising to R2 saying, hey, I've
got a local label for 4.4.4.4. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
got a local label for 4.4.4.4.
So how does R2 know whether it should
use the label R1 supplied, and send it
that way when it's trying to forward a packet,
or whether it should impose the label R3 is using,
and send it over here to R3?
And that's exactly what we're going
to discuss right now by taking a closer look at R2.
So here in R2, I'm going to just show MPLS LDP bindings.
And we can look at all the bindings,
or we could limit it just to 4.4.4.4
for the purposes of this demonstration. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
for the purposes of this demonstration.
So let's do 4.4.4.4 and we'll specify
that it's the 32-bit route.
So here is what it says.
This is R2 telling us, yeah, OK, regarding
4.4.4.4, my local label that I chose is 202.
Fantastic.
And I heard from my LSR buddy 1.1.1.1, which is R1, about
its local label, 102, and I also heard about, from R3,
its local label of 302.
So if I ever need to forward a packet to 4.4.4.4
and I need to impose a label on it, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and I need to impose a label on it,
which one are we going to use?
Are we going to impose 102 and send it to R1,
or are we going to impose the label 302 and send it to R3?
It's a great question, and it's based--
in the background it's based on the IP routing table.
That's how it sorts it out.
So if we do a show ip route, and we'll look for just 4.4.4.4,
check this out.
It's learned via OSPF, and the next hop is 10.23.0.3.
And we can also show IP route and just
pull it from the routing table along with all the others, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
pull it from the routing table along with all the others,
but this is saying that the next hop is 10.23.0.3
and the egress interface is gig 1/0.
So the key is--
what needs to happen is, if we get a packet
that we need to impose a label on to go to 4.4.4.4, what
we want to do is choose the LDP neighbor
and its associate label who owns that next hop of 10.23.0.3.
So to find that, we do a show mpls ldp neighbor,
and here it's showing us the details for both neighbors. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and here it's showing us the details for both neighbors.
And check this out-- for 1.1.1.1 here's
its addresses associated with it,
and for 3.3.3.3 here is the addresses associated with it.
So if we take a look at that next hop, which was--
let me scroll up a little bit here--
the next hop was 10.23.0.3.
If we look for the neighbor that owns that address,
it's this guy right here.
It's 3.3.3.3, which is R3.
It owns that next hop, and as a result,
we're going to use R3's label and the interface
to reach R3 as we send that packet on its way. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to reach R3 as we send that packet on its way.
And we can verify that with a show mpls forwarding-table--
that's the winner's table for what we're actually
going to do after all's said and done,
and this says right here for the 4.4.4.4 network,
we are going to impose 302, which is R3's local label.
And then when R3 gets a packet with that MPLS label,
it will go ahead and follow its instruction based
on its MPLS forwarding-table.
So I thought what would be fun is, let's do this.
Let's go to R1.
And if we do, oh-- we have a trace right there
from our previous lab, so if we do a trace again, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
from our previous lab, so if we do a trace again,
here's the labels that are going to be
involved in going to 10.44, and let's go back and look at R2.
And here's the MPLS forwarding-table
for that network.
So R1 should impose label 204 for the benefit of R2.
R2 should pop that off, impose label 304
as it sends it out gig 1/0 on the way to R3.
And also I'd like to do this as a demo.
Let me do a packet capture of the traffic, where we can
actually see the MPLS label.
So let's capture-- let's capture right here between R2 and R3. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So let's capture-- let's capture right here between R2 and R3.
So what we expect to see is the associate label
that R2 as imposing as it forwards that traffic over
to R3.
So what we do is we do a capture, and from R1 one
we could ping 4.4.4.4, and we could also ping 10.44.44.44.
So let's take a look at both those
and predict what labels we would expect
to see between R2 and R3, and then we'll go ahead
and I'll do a capture, and we can
verify that what we expected to happen is actually happening. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
verify that what we expected to happen is actually happening.
So right here in R2, we can look at both those networks.
We would expect label 302 to be imposed if the traffic is going
to 4.4.4.4, and we could expect the label of 304
if it's going to 10.44.44.44, so 302 and 304.
And we could verify that just by doing a trace right here at R2.
If we did a trace to this address, 4.4.4.4--
I'll just go ahead and copy paste it--
there we go.
MPLS label 302 was placed on there by R2. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
MPLS label 302 was placed on there by R2.
And if we did a trace to 10.44.44.44,
we would expect label 304.
And there it is.
So the cool thing is that, in the background,
I also did a packet capture of that traffic
on the wire between R2 and R3.
We can also take a detailed look at those packets
and verify the MPLS labels.
And here we go.
So in this packet capture, if we look
at some of the initial ones here that were going to 4.4.4.4,
here we have the Ethernet header-- fantastic. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
here we have the Ethernet header-- fantastic.
Here we have the IP header-- fantastic.
And in between those, here we have the MPLS header.
And so it's label 302 in the MPLS header for the destination
4.4.4.4.
And if we go to a packet destined for 10.44.44.44
the MPLS label is 304.
In this set of videos, we've taken a look at MPLS--
multi-protocol label switching, which allows
routers in the middle of our network
to never have to look at the IP information layer 3.
All they do is, they get a packet in, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
All they do is, they get a packet in,
they look at the MPLS label thing--
oh, I know to do that-- they swap it out with the next one,
and they forward it without ever having
to look at the IP header.
Now that brings us a whole world of benefits,
including something called layer 3
VPN that we can run in a service provider
network that is using MPLS.
And that is the topic of our very next set of videos,
so I hope to see there in just a few moments.
Meanwhile, I hope this has been informative for you,
and I'd like to thank you for viewing.