[AUDIO LOGO]
The MPLS forwarding label, the label
that's normally learned from LDP is generally
used to forward the traffic through our MPLS
core from the ingress PE's loopback
to the egress PE's loopback.
Now, the egress PE generally knows the customer's routes.
However, the PE routers in the middle don't.
And that's why we need this label.
In the case of the forwarding label,
we're just worried about getting the traffic between the two
PEs.
The egress PE will then handle it from there.
So it's a pretty good argument to say that the egress PE does
not need to know the forwarding label for its own loopback.
It knows how to get to its own loopback interface, which
would be the BGP Next-Hop because, of course,
it's directly connected.
And because of this, MPLS implements
a feature called PHP, or Penultimate Hop Popping.
Now, we've seen this in use through some
of our previous demonstrations and, of course,
it's on by default because we've seen it operate.
What we want to look at in this video
is some situations where maybe PHP doesn't work out
the best for what we're trying to accomplish.
There are reasons we may need to disable it or turn it off.
And in that case, instead of it being an implicit null,
it's going to be an explicit null.
And instead of using label 3, like we do for PHP,
we will use label 0.
And we'll see this as we progress.
So let's jump into our topology diagram,
just take a look at the path that we're
going to be examining our traffic on
and then we'll jump into the command line
and see how to operate with PHP.
So in this skill, we're again, going to be on MPLS topology 3.
And for this particular demonstration,
we're going to be starting off on router 6,
and we're going to be looking at the traffic flow that's
going from router 6 through our core to router 8.
Now, keep in mind we do have multiple paths here,
so it very well could be multipathing and taking
this lower path, but our main focus is, of course,
going to be on these links right here, that last hop before we
get to router 5 because router 5 is the one in this example that
would be doing PHP.
This is going to be about what label router 5 is generating.
So let's go ahead and jump into the command line
and take a look at some of the details of PHP.
So let's start off by tracing our path to the 10.100.10.8,
which is the client side of router 8.
And if we examine our trace here, a couple of things to
note.
First, we can see that it is, in fact, load sharing
through our core here at hop 2 where it's
going to both routers 3 and 4.
But notice as it's going towards routers 3 and 4,
it has 2 labels on it.
For example, towards hop 4 here, it's using label 24403,
and then it's got the VPN label 24507.
Now, we know that's the VPN label for two reasons.
One, it's the second label.
Two, the numbering that we used when we built our lab.
The fact that the third digit is a 5
means that this label was generated by router 5
because that's how we built our environment.
And we see that when we send the traffic towards router 3,
it's using a different forwarding label,
in fact, one from router 3, the 24302,
and it's using the same VPN label because, again, that's
originated from router 5.
But then notice that when both 4 and 3 forward this to router 5,
router 5 is only getting one label.
It's only getting the VPN label, the 24507 because of PHP.
So let's start taking a look at what this can actually cause.
And one of the biggest issues for PHP
is going to be QoS, particularly if we
want to work with QoS in the core of the service provider
environment.
So let's take a look at what that means
and how PHP affects that.
The easiest way to start seeing this problem
is we're going to configure router 6 to just start
marking all of its traffic as it sends it
out that interface towards the MPLS environment.
And we'll just set it to IP precedence 3.
So let's just jump in and configure that.
We'll go into configuration mode,
we'll write a QoS policy map.
We'll call this PM_SET_IPP for IP precedence.
We'll simply do this in class class-default, that
will affect all traffic.
And we'll say set ip precedence, and like I said,
we'll set it to 3.
It doesn't really matter, we're just looking for the marking.
We'll go into our interface, gigabit 1 which, of course, is
facing the MPLS environment, and we'll
apply this policy outbound.
We'll exit configuration.
And let's do our trace again.
If we take a look at this output,
we can see that MPLS has taken the IP precedence field
and automatically copied it onto the MPLS label
when the label is imposed.
So if we look at this output, it looks like Exp 3,
or IP precedence 3, is making it the whole way
through our environment.
We see it on each and every hop, until of course,
we remove everything and send it out to router 8.
But we're not worried about outside of MPLS right now.
So here's the point.
If all we were trying to do was get a customer's QoS markings
all the way through our environment,
this would be fine.
We can see that this QoS marking is,
in fact, making it the whole way through the environment.
Where the problem comes in is what if we as service providers
want to use the Exp markings ourselves?
That's where the problem comes in, let's take a look.
So let's go over to router 1.
We'll make a policy map.
We'll call this PM_SET_EXP.
For our class, we'll again use class-default.
And what we want to do is set the MPLS EXP bits.
But something sort of important to note here,
there's only two choices.
The first choice is on imposition.
And we don't really want to use that one
too often because usually we're not
going to be changing QoS markings on the same router
that's imposing the label.
Now, in this particular case, router 1
we could possibly do that.
But the other choice is topmost or the forwarding label.
So what if we change the forwarding label,
and we want that to go through our MPLS environment?
Well, let's set the topmost label
and let's change it to something different.
So we'll say, topmost--
and let's mark it down.
Let's say we're going to degragate
the traffic a little bit.
Let's mark it down to 2.
Let's go into our interfaces now,
and these are going to be the interfaces facing the MPLS
core.
We do our service policy out and we apply our policy.
Now, since we are doing load sharing,
we want to make sure we cover both possible paths.
So let's apply this to interface gigabit 2 as well.
Commit our changes and we'll exit configuration.
Now, let's go back and look at our trace again.
So we'll do our trace and right here, we see the problem.
We as service providers are trying
to mark this traffic down for whatever reason to Exp 2.
And as we can see on the second hop here,
we have, in fact, put on a marking of Exp 2.
So our policy worked.
Here's where the problem comes in.
Notice that on hop 3, when PHP happens
and router 5 tells us to pop that label,
well, we pop the top label.
That's the one that we marked.
So the marking or the change that we made is now lost.
Now, there is a possibility that we only wanted this change
to affect all of the PE routers in our environment
and we don't really care if this Exp marking of 2
makes it all the way to the egress PE.
And if that's the case, then we could end our discussion
right now.
But to sort of prove the point that we actually do sometimes
need this marking to make it all the way
to the egress PE, that's where we're going to need
to turn off or disable PHP.
Now, just a quick note here, we're
talking about getting this marking to the egress PE
so that the egress PE can do something with it
or act upon it.
This is not talking about this change going all the way
to the customer.
If we want this change to go all the way to the customer,
that's a different discussion and we'll
have to talk about that in a different skill.
But for right now, we need to at least get
the marking to our egress PE.
So let's turn off PHP and see what happens.
So let's start by looking at what's
going on router 3, our P router that's directly connected
to router 5, our egress PE.
So if we do a show MPLS forwarding table
and we look at router 5's loopback, which
is, of course, where this traffic is headed,
notice that it is currently set to Pop.
Pop is PHP-- that means pop 1 label, but leave on the rest.
That as opposed by the way to going to say,
for example, router 12 here, where it's unlabeled,
that's because the interfaces going up to our route reflector
are not even running MPLS.
They don't have to.
They're not in the MPLS forwarding path.
So Unlabeled means remove all labels,
Pop means remove just the top label.
So now let's see what happens if we go
to router 5 and turn off PHP.
On IOS XE this is a very, very simple command,
it's mpls ldp explicit-null.
That's it.
We hit Enter, we can exit out of configuration.
Let's go back over to router 3 again.
And if we look at our forwarding table again,
now it says explicit null for IP version 4.
So now let's go all the way back to router 6
and see what happens with our trace again.
So two things to note here, again, particularly on hop 3.
First is notice the forwarding label is label 0.
Explicit null uses label 0 for the forwarding label.
And the second thing is that our Exp marking of 2
has now made it all the way to the egress PE who could then
do something with it if we wanted to.
So now what about going the other direction?
Let's hop up to router 8, and let's trace the other way.
Let's go 10.100.1.6.
Now, here we're not going to bother
with setting the IP precedent and all that because we've
already seen how that works.
But notice that at hop 3, we are popping the forwarding label.
So we have the same thing going on the other direction.
So of course, what this is about is seeing
how to turn off PHP on IOS XR.
So now let's go disable PHP on router 1.
So we'll go into configuration mode,
here the command is mpls ldp address-family ipv4 label
local, and then we hit the question mark
to see our choices.
Now, we have sort of two major choices here.
First, we could do an implicit-null-override,
and then it wants the word "for," so OK, for what?
An IP access list.
So with this structure does is it
allows us to disable PHP or enable explicit null, whichever
way you want to say that, but it allows us to do it just
for specific prefixes.
Now, we don't have to quite get into this level of detail
here, but just be aware that we can do it.
The other choice we're going to do here next
is to do it for all the prefixes.
Sort of like what we did on router 5,
we just turned the feature on, and that was it,
it did it for everything.
So that's what we're going to do here.
To do that, we're going to go back to the word "local,"
and instead, use this other choice, advertise,
and we simply say, explicit-null.
So the command is quite a bit longer,
but this is the equivalent to the command
that we put in on router 5.
So let's go ahead and commit that change.
We'll exit out of configuration mode.
For verification, let's hop back over onto router 3 again.
Notice here that when we looked at it earlier,
router 1 was Pop, and now we're expecting
it to look like explicit null just like Router 5 does.
And we can see, in fact, that it does.
They're both set to explicit null now.
So of course, let's go back to router 8, do our trace again.
So we can see that this is acting the same way where
it's now using a forwarding label of 0.
So in this video, we saw how to handle PHP, its default
behavior, as well as things that can be affected
by that such as QoS markings.
And because of that, we also saw how to turn off PHP,
or you could say turn on explicit null.
We also saw that when we do turn on explicit null,
it uses a label of 0 as opposed to implicit null, which is
PHP, which uses a label of 3.
Now, we also want to take a look at
some other advanced features, such as TTL propagation
and how the TTL is handled in this same environment.
And that's exactly what we get to do next.
Until then, I hope this has been informative for you,
and I'd like to thank you for viewing.