[AUDIO LOGO]
So now that all of the other components
have been configured and verified,
it's now finally time to actually configure
our segment routing TE policies and tunnels.
That's, of course, what we're going to be
doing in this demonstration.
So that said, let's take a look at our topology, just
so we know what we're going to be building on which devices.
And then, of course, we'll jump into the command line
and get all of this configured and operational.
So of course, one final reminder,
we will, of course, be finishing up here on MPLS Topology 5
because this is where everything is configured.
But specifically, what we're going
to be doing in this demonstration is
we have a network on router 7 and a network on router 8.
Their IP addresses are hundreds 100.7.7.7 and 100.8.8.8.
And we'll be configuring our segment
routing TE tunnel so that these two
networks are reachable through our environment.
So let's go ahead and jump in and get started.
We'll just begin our configuration on router 7.
So let's begin our configuration by setting
a few of our parameters for the tunnel.
So we'll start with MPLS traffic engineering.
And we're going to build this as an auto-tunnel.
It's going to be point to point.
And we're going to set a configuration parameter here,
where it's going to be unnumbered off
of the interface loopback 0.
So it's going to pull the address for the tunnel off
of loopback 0.
The other thing we want to configure is the tunnel number.
So we'll set the minimum number to, say, 1,000.
That should be the one it uses first.
And then we'll say the max is like 1,900.
It doesn't matter.
Of course, we're going to get nowhere near that number.
So that configures some of the parameters for our tunnel.
The next thing we want to do is create a list of attributes.
So we do this by saying mpls traffic engineering lsp.
And then we're going to create an attribute list.
And we'll call this LL_TRAFFIC.
Now, what do we want to configure here?
Well, let's first tell it how much bandwidth
it's going to use.
So we'll say the bandwidth is 1,000.
We'll also set the priority.
We'll set the setup and the hold priority, both, to say 5.
For the path selection, let's set it
to the traffic engineering metric.
And we'll tell it to use PCE.
That should take care of our attributes.
Now, this next command is optional.
But it will make some of our show commands
a little bit easier to look at.
So we'll just put in ip bgp-community new-format.
Again, that's just a display command for BGP communities.
Because we're going to use communities
to influence which routes we're going
to put these attributes on.
Now, in order to do that, we are going to need a community list,
standard community list will be fine.
We'll call this CL_LL_TRAFFIC.
And we'll say that it's going to permit 100 colon 10, just
to pick a community string to use.
Next, we're going to need our route
maps for our inbound and outbound BGP updates.
So first, we'll create a route map called IPv4_IN.
We'll say to match community and put in our community list.
So this will only be applied to traffic that
has the 100 colon 10 on it.
And what we want to do with that traffic
is we want to apply the attribute set
that we created earlier.
So this is going to apply those tunnel attributes
to any routes coming in with this community string.
For our outbound route map, which we'll just call OUT,
for this one, all we want to do is set the community
so that this triggers the policy when our routes get
to the other side.
Because router 8 is going to be a mirror of this configuration.
So we're going to set community to 100 colon 10.
Next, of course, we're going to have to configure our BGP
parameters.
So we'll say router BGP 100.
Now, the first thing we're going to have to do
is put our own network into BGP.
So it's 100 colon 7 colon 7 colon 0.
It's actually a slash 24.
So we'll say that the mask is 255.255.255.0.
And we'll run this route injection
through the route map we created for our outbound updates.
Now, since we're going to be using communities,
we're also going to have to configure towards the route
reflector to actually send communities.
And we'll turn on both.
I normally turn on both standard and extended communities,
if I'm going to enable this feature.
Although right now, we're only using standard communities.
Also, towards neighbor 10.11.11.11,
we need to apply our inbound route map.
So we'll say route map IPv4_IN.
And again, we're going to apply that in the inbound direction.
Let's exit configuration.
So now, we have to configure essentially the same things
over on router 8.
So let's jump over there.
So let's go into configuration mode.
Now, these are a lot of commands to put in,
so we will copy and paste them.
But we will do it piece by piece so we can talk
about what we're putting in.
So the first piece are the two commands that set up
the parameters for the tunnels.
The next piece is to define the attributes.
Next, we'll configure our new format
and configure our community list.
Next, we'll create both of our route maps.
And then finally, we'll configure BGP.
So now that both sides are configured, let's
do some verification.
Let's do a show mpls traffic engineering tunnels.
And we can see that we have a point-to-point tunnel going
from router 8 to the destination of 10.7.7.7.
This is tunnel 1,000.
Status is admin up.
It's operationally up.
The path is valid.
The signaling is connected.
And it's using path option 1 segment routing,
coming from PCE.
So these are, of course, good indicators
that our PCE is working, our segment routing is working.
And if we look under our configuration parameters,
notice that it has all of those things that we configured.
It's got our bandwidth in kilobits per second.
It's got our priorities.
It's using the metric type of TE from the interface.
So all of this looks good.
We can also, by the way, add the command tunnel 1000 detail.
And this would give us a way to look at a specific tunnel.
And again, there's a lot more information
here when you do detail.
We, of course, don't have to look at all of this right now.
But there's a lot of information available if we need it.
And one really interesting piece is down here
at the bottom, where we can actually
see the segment routing path that it's
using, where it's going to router 5, from 5 to 3,
and then over to 7.
So we can actually see the segments
it's using as it goes between the domains.
We should be able to see this from the router 7 side as well.
So on router 7, if we look at just the tunnels,
once again, we see this same information,
that going to the destination 10.8.8.8
is up, operational, and valid.
We see all of our parameters configured here.
So this all looks good.
And again, we can look at the detail for the tunnel.
And here, we can see the segments
that it's going through, from router 7's perspective,
to get to the destination.
Of course, we can also verify this on the PCE itself.
So let's go up to the route reflector.
So let's do a show PCE LSP.
First thing we see is that we do have a tunnel
1,000, one going from router 7 to router 8 and one going
from router 8 to router 7.
We can see that both of them are admin up and operationally
active, that they're using segment routing.
And we see the binding SID that's
being used to get traffic to go to the other side.
Now, we do have one more small problem
that we actually need to fix.
Let's go over to router 7.
And the problem here is, if I do a show BGP,
we're getting that route to the 100.8.8.0/24.
However, it's not valid.
And the problem is, if I ask for detail on that network,
it's telling us that the next hop is inaccessible.
Of course, that's because if I do a show IP
route for 10.8.8.8, we have no idea where it is.
It's in another routing domain.
I don't know where that is.
Now, the interesting thing is, all we need to do
is trick the router to actually just send
the traffic to the tunnel.
Because notice, it has the binding SID on it.
It actually knows what to do with this traffic,
but BGP won't do it because it thinks the next hop is
unreachable or inaccessible.
So yes, we can in fact trick it.
We'll put in IP route to 10.8.8.8.
And we'll simply direct that to null0.
Now, we'll have to do the exact same thing on router 8
because it'll be having the same problem.
So again, if we do show BGP, just so you can see it,
again, there's the 100.7.7.0.
And it's not selected as best.
So we'll go into configuration mode
and configure our static route.
So let's go back over to router 7.
Hopefully, that gave BGP enough time to converge.
We see that now, that path is selected as best.
Let's verify router 8 as well before we test the data plane.
We see that router 8 is also listing the route as valid now.
So let's test some traffic.
So here on router 7, let's trace to that
100.8.8.8, sourcing it from our loopback 100 interface.
So here, we can see our labels being
applied as they should be.
And we see that we reached our destination.
Now, it is OK for some of the interim devices
to not necessarily respond to the trace
because they may not know how to get back to the source address
that these packets are originated from.
But let's verify that our tunnel the other direction
is working as well.
So again, we'll trace back to router 7.
So again, we see that this is working.
So now, we have our traffic engineering tunnel operating
in both directions, set up between two different domains,
using a PCE.
In this video, we saw how to configure our tunnel
parameters, create an attribute set,
create our route maps to apply those attributes
to incoming routes.
We filtered that, of course, also using community strings.
But then ultimately, we saw how this
builds the tunnel using PCE.
And we ended up with a fully functional data plane,
going both directions, using our traffic engineering tunnel.
So that concludes everything that we
need to learn in this skill.
That means that all we have left is
a review in the form of a quiz.
And of course, that's what we're going to do next.
Until then, I hope this has been informative for you.
And I'd like to thank you for viewing.