[AUDIO LOGO]
So let's go ahead and jump in here with trouble ticket 1.
For this trouble ticket, we're going
to be using MPLS topology 3.
So let's go ahead and take a look
at what our ticket actually says.
It says that R3 is forwarding traffic to R5 loopback
interface without any labels.
So what that basically means is we're
going to have to look at the connection between router 3's
loopback and router 5's loopback, which it says
we don't have any labels for, which
means we're going to be focusing probably on this connection
right here to see why labels aren't being exchanged.
So that said, let's jump into the command line,
and of course, we like to start with verifying the ticket.
So let's take a look at the MPLS forwarding table on router 3.
So looking at our show mpls forwarding table,
what do we see?
We see that going to the destination 10.5.5.5/32,
it says that it's going to be sent unlabeled.
Well, that's interesting.
Let's see if we have any binding for that network.
So we'll do a show mpls ldp binding for 10.5.5.5/32.
What we actually see is we are getting labels for it, but only
from routers 1, 2, and 4.
Now those labels aren't going to be used because they're not
on the IGP forwarding table.
In other words, our outgoing interface
is towards router 5, not towards routers 1, 2, or 4.
So even though we have labels from our other peers,
not having a label from router 5 means it's not
going to be a usable label.
In fact, if we do a show ip cef, since the ticket
was originally that we're not imposing a label.
If we do a show ip cef for that prefix,
what we see is that we have a remote adjacency to that prefix
out our gigabit 0/0/0/0 interface.
And here is, of course, the important part,
labels imposed none.
So we are not putting a label on going towards router 5.
So our trouble ticket was definitely correct.
We would be forwarding traffic to router 5's loopback
as standard unlabeled IP traffic.
So now let's see if we can try to figure out why.
Well, maybe router 3 here isn't even running MPLS or LDP
on the appropriate interfaces.
So let's do a show mpls interface.
We see here that we are, in fact,
running MPLS with LDAP on our gigabit 0/0/0/0 interface.
So let's see if we have any neighbors.
Let's do a show mpls ldp neighbors brief.
We have neighborships with router 1, router 2,
and router 4.
But again, we see router 5 is actually
not one of our neighbors here.
So I think we're starting to get to where the problem may be.
We don't have an LDAP neighborship with router 5.
But all of that said, router 3 here
doesn't seem to be the issue.
Router 3 has MPLS enabled on its interfaces,
LDPs enabled on the interfaces.
So I think it's probably time to jump over and take
a look at router 5.
I have a suspicion that that's where the problem is.
So hopping over to router 5, let's do some testing here.
Let's start with our show mpls forwarding table.
So we have a lot of entries here.
However, we notice that all of these entries
have something in common.
They all say no label.
There's no outgoing label.
So if we do a show mpls ldp binding,
it says TIB not enabled, which is the tag information base.
Just for a small piece of history here,
Cisco when first implementing MPLS called this tag switching.
So we even had a protocol called TDP or Tag Distribution
Protocol.
Of course, it got replaced by the standard MPLS with LDP.
However, some of the outputs, as you can see,
this one, for example, still has a tendency
to refer to them sometimes as tags rather than labels.
And of course doesn't affect anything as far
as functionality.
But sometimes you'll see an output like this
and be like TIB, what's the T?
It's tag if you ever happen to run into this.
But at the end of the day, what that actually means
and the fact that we have no labels for anything,
really looks like MPLS isn't running
at all here on router 5.
Let's try a show mpls interface.
So that's a spectacular output.
We have no interfaces running MPLS.
So clearly, this is going to be a problem.
So the way we need to fix it is to enable MPLS
on our interfaces.
But which interfaces?
Well, let's take a look back at our diagram.
And we can see based on our diagram
that we need to be running MPLS on this interface, which
is gigabit 1.3 and on this interface, which
is gigabit 1.4.
So those are the two interfaces that we're going
to have to enable MPLS on.
Let's jump back over to router 5.
And let's configure MPLS.
So we go into configuration mode, into interface gig 1.3,
and all we have to do is type MPLS IP to enable MPLS here
on IOS XE.
And we'll do the same thing with 1.4.
And look, we can see we already have neighborships coming up.
So it's a pretty good indication that, that
was at least a problem that we have in our environment.
Let's go ahead and verify, let's do a show mpls interface again.
We see that now we have our two interfaces,
they're running LDP, and they are both operational.
So now we should have some LDP bindings.
Obviously, there's a lot of entries here.
We don't have to look at every one of them.
But now we're getting entries where previously this list was,
of course, completely empty.
And if we do our show mpls forwarding table,
now some of these are still no label.
Those would be interfaces going to customers and such.
However, all of the entries for our core network
have labels associated with them.
So this looks like it's functioning properly now,
but the ticket was for router 3.
So we should verify this on router 3 as well.
So let's just verify some of the commands
we looked at originally.
We'll start with our show mpls ldp neighbor brief.
We can see that router 5 is, of course, now on this list.
If we do a show ip cef, we can see
that we're now imposing the implicit null label, which
is pop or label 3.
So that would be correct.
If we look at our MPLS LDP binding for that entry,
we now see that we're receiving the implicit null label
or again label 3 from router 5.
And the most important is if we do our show mpls forwarding,
when we look at that entry for 10.5.5.5,
it is now set to pop instead of unlabeled.
So that means that it will be forwarding the traffic
with any necessary VPN labels.
So yes, it will still pop the forwarding label,
but any other labels would still be intact.
So pop is acceptable for this situation.
So in this video, we saw an example
of how our environment will react if one of our routers
is not properly configured with MPLS
on the appropriate interfaces, or in this case,
it didn't have it on any of its interfaces.
So we actually fix something that wasn't part of the ticket,
but was clearly a problem because router 5
didn't have MPLS on either of its interfaces,
even though technically the ticket only specified
that the router 3 side was an issue.
Clearly, it was going to have the same problem towards router
4.
So we fixed that along the way.
I hope this has been informative for you.
And I'd like to thank you for viewing.