So now, that we've got PHP all squared away,
let's jump in and take a closer look
at TTL propagation in MPLS.
The default behavior for TTL propagation
is that when the label is imposed onto the packet,
we take the original IP TTL and copy that to the new label TTL.
Now, this has some advantages and some disadvantages.
The advantage is things like trace route
and maybe some other utilities will still work properly.
The downside is, our customers can actually
see the entire core of our network,
and we may not necessarily want customers
to see all of the P routers in the center of our network.
So let's jump in, take a look at what TTL propagation does
by default, and then of course, we'll
take a look at how to alter that behavior.
And we actually have a couple of options
that we need to look at.
So of course, we'll start looking at the topology
just as a reminder of how everything's set up
and the traffic flow we're going to be examining,
and then we'll jump on to the command line
and check out what TTL propagation is all about.
So our topology here is really just a reminder for you
of how everything is set up.
We're going to start this discussion
by focusing on the traffic coming from router 6,
going to router 8.
And again it will be probably multipathing here
in the middle, but the real question
is, will we be able to see the path in the center,
and that's what this discussion is all about.
So let's go ahead and jump in to the command line
and play around with TTL propagation.
So let's begin by looking at the actual problem, if we actually
want to call it a problem.
But let's do a trace to 10.100.10.8 here on router 6.
So again, we're tracing to a network on router 8.
And the big problem we have with this output
is specifically, that we're seeing router 3.
We're not really so concerned that you
can see router 1, because router 6 is already
in OSPF neighbor with that router anyway
and sort of the same with router 5.
Router 5 and router 8 are already OSPF neighbors,
so from the customer's perspective,
we're already going to know where the PEs are,
we're aware of the PEs, so it's really about router 3
here, which is a P router, and the customer really
shouldn't be able to see that.
So let's go over to router 1 and turn off our MPLS TTL
propagation.
So the command for this is MPLS IP TTL propagate,
and we say disable.
We'll commit those changes, and we
can exit out of configuration.
So now, of course, let's go back to router 6
and see what it looks like now.
We'll do our trace again, and as we've already mentioned, yes,
we still see router 1.
Yes, we still see router 5.
We knew about those anyway, but we lost the P router.
We don't see it anymore.
And while we're doing this trace, why don't we
hop into Wireshark, capture one of these packets,
and take a look at what it's actually doing.
So we have our Wireshark capture running.
Let's go ahead and do our trace again, and then let's
get back over to Wireshark.
So what we see in Wireshark is, if we look at this UDP packet,
going from 192.168.16.6 to the 10.100.10.8,
which is packet 29 here, we can actually see a few things
of interest.
First, notice what's going on.
We have two labels here.
We know that the 24.302 is the forwarding label,
and we know that label 24.507 is the VPN label.
And if we look at the Exp bits right here on these packets,
we can actually see our QOS from our previous lab
still in place, and we see how it's only
marking the Exp on the forwarding label
and not on the VPN label, which of course, is
exactly what we're expecting from the behavior we
saw in our previous video.
We also see how the S bits work here.
We see that the S bit on the first label
is, of course, not set because it's not the bottom of stack,
and the S bit on the VPN label is set.
And then of course, what we're really here to look at
is the TTL.
When you disable TTL propagation,
what the router does is it just sets the TTL to 255.
And since we're capturing this right
on router 1, which is where we're imposing these labels,
we see that it's right at the value of 255.
So this all looks like it's working fine,
but we do have one issue that we probably want to look at.
Let's go back over to router 1.
So here on router 1, we may have an unintended consequence
of what we've done.
If we were to say to trace, to router 5's loopback, sourcing
it from our loopback interface, this
appears like we're directly hitting router 5.
Now, I'm pretty sure if we go back to the diagram,
that router 1 is not directly connected to router 5.
We have routers 3 or 4 in there, and it's probably, again,
multipathing.
We could actually tell that from the trace,
because it's actually hitting router
5 on the two different interfaces, 35, 5 and 45, 5.
So we can actually sort of tell from the trace
that it's load sharing, but the point
is we're not seeing routers 3 and 4, which
are part of our own topology.
So as the service provider, yes, we
wanted to hide this MPLS core from our customers.
That doesn't necessarily mean that we
wanted to hide the core from ourselves.
Now, the cool thing is, we have a real easy addition
to this command we can put in that
will solve this problem completely,
and this is generally how I would recommend
running the environment.
So we simply go back into configuration mode,
and we go back to the previous command we put in
and we simply add this one key word to it, which is forwarded.
This will have it not propagate the TTL on forwarded packets,
but if it's locally generated, it will still do so.
Now, you can see you can actually
choose the opposite option, if you want.
I'm not sure of a practical use for that,
but I'm sure there's one out there somewhere.
I always just do the forwarded, we'll commit our change,
and now, let's do our trace again.
If we do it a few times, we might
be able to see that it's actually hitting router 4,
so yeah, here we can see it hits router 4 for the first hop.
One of the downsides of equal cost multipathing
and the way the trace works, the trace
sends three copies of every frame,
which means it's going path 1, path 2, path 1.
So the next time, it's going to do path 2, path 1, path 2.
So it can make our traces look a little bit
interesting with the multipathing,
but the fact of the matter is that's what it's doing,
and here, we're seeing routers 3 and 4.
So we can still troubleshoot the core of our own network.
Yet, if we go back to the customer, on router 6,
and we do our same trace again, router 6, the customer,
still doesn't see the core.
So ultimately, I think this is the best solution.
The customer doesn't see the core,
but those of us who work at the service provider,
we can still use tools like traceroute and things
like this to actually be able to troubleshoot
the center of our core.
Now, of course, we would want this
to work in both directions, and if we go over
to router 8 right now, we'll find out that it's not.
If we do the trace 10.100.1.6, notice, it's seeing router 4,
so we can still see the core of this direction.
So we need to turn this off on all of our PEs.
Now, router 5, since it's, of course, running iOS XE,
is a little bit of a different command.
We simply go into Configuration mode,
and it's no MPLS IP propagate TTL.
And again, it has that option to do forwarded or local,
so of course, we'll do forwarded.
Now, that that's in there, this should now
be functional both directions.
Let's just verify from router 8.
Do our trace one more time, and now, we do not see the core.
So the core is now hidden in both directions.
So in this video, we took a closer look
at the TTL operation in MPLS.
Remember, that the default on both iOS XE and iOS XR
is to take the TTL from the original IP packet
and put it onto the new labels.
However, this can be disabled, and if we do so,
we get the benefit that the customers can't see the core,
but we can do it just for forwarded traffic
so that we can still troubleshoot
the core of our own network.
Also, keep in mind that if it doesn't propagate the TTL,
it just flat out sets it to 255.
So that takes care of TTL propagation.
Up next, we want to look at route leaking.
Sometimes, we might need to get routes
either between the global table and a VRF
or maybe between VRFs of different customers.
And that's exactly what we're going to take a look at next.
Until then, I hope this has been informative for you,
and I'd like to thank you for viewing.