[AUDIO LOGO]
So the next thing we want to look at
is actually leaking routes between VRFs
or between the global routing table and a VRF.
Now, we already know that we can move routes between VRFs
using route targets.
We've configured our import and export route targets
under our VRFs.
And of course, that's what we've used to control which
routes go into which VRFs.
We would generally consider that normal layer 3 VPN operation.
What we're talking about here is doing it just for some routes.
The problem with doing the import and export route targets
is, it would do all the routes in the VRF.
And maybe, we just want to leak a small portion of them.
So the main thing we're going to do
is something called an export map.
And we're going to use that to put a particular route
target on just a subset of the routes in a VRF.
Now, there's another interesting feature
that we're going to look at on IOS XE.
But we'll save that until we get to look at it.
So let's go ahead and jump in, look at the topology.
We're going to be doing this between customer A and customer
B on router 5.
But let's just take a look at where that is.
And then, we'll jump in to the command line
and get some routes leaking between the two customers.
So as we jump into this demonstration,
remember that there are actually three VRFs on router 5.
We have two for customer A and one for customer B.
And what we're going to be doing is
leaking routes between essentially router 8 and router
10 and, therefore, get connectivity
between these two routers, between the two different VRFs.
So let's go ahead and jump into the command line
and take a look at how this works.
So to start with, let's leak router 10's loopback
into the VRF customer A1.
Now, in order to do this, the first thing we're going to need
is a prefix list to match on router 10's loopback.
So we'll call this PL_CustB_EXPORT,
and it will simply permit router 10's loopback.
The next thing we're going to need is a route map.
We'll call this RM_CustB_EXPORT.
It will match on the prefix list that we just created.
And the key here is, we're going to use this
to set the extended community.
And we're going to add a route target to it.
The route target that we want to add,
we can really just use pretty much whatever.
We'll just use 100:500 for this example.
But here's a real key.
We need to make sure that we do this additive.
If we don't do it additive, this will actually
overwrite the existing route targets.
In which case, this wouldn't get sent
to customer B's headquarters.
So we want to make sure we're not actually breaking anything
when we do this adding of the route target.
So we need to make sure we put additive on there.
Then, we'll go into the customer's VRF,
into the address family, and we'll
add this as an export map.
So it's going to be RM_CustB_EXPORT.
We'll exit configuration.
And now, let's verify that it's actually
added that route target.
So we'll do a show bgp, vpnv4 unicast for the VRF customer B,
and we'll look for the 10.10.10.10.
And we see that, so far, it still just has
the normal route target on it.
So what we're going to do is, we're
going to have to clear this.
So go ahead and clear the connections.
And if we take a look at the command again,
now we see that the route target 100:500 is on this update, as
well as the route target for customer B, which
is the 100:2000 that we've been using this whole time.
So, so far, we've added an export route target
on this update.
Now, we have to get this update to get into customer A's VRF.
And specifically, we're going to be doing it
into customer A1's once VRF.
So we'll go back into configuration.
We'll go into the customer A1 VRF,
and we'll do a route target import of the 100:500.
So now, we should take any routes
with the 100:500, which is now router 10 loopback,
and put that here in the customer A1 VRF.
So let's go ahead and look at the routing table
for customer A1.
And what we see right here is this BGP route for 10.10.10.10.
And we can see a little bit further here
in the line, where it actually tells us
that this has been imported from customer B VRF.
So now, we have a route leaking from the customer B VRF
into one of the customer A VRFs.
Now, we could, of course, do the opposite
to get a route from customer A to go to Customer B.
And that would give us reachability.
However, we want to explore a different option.
IOS XE has a unique way that we can do this.
So let's go ahead and take a look at that.
Before we do that, however, let's make
sure that route's getting all the way out to the customer.
We'll just do a show IP route, and we
see right here that it is.
It's coming in as an OSPF external type 2,
and it's, of course, pointing to router 5 as the next hop.
So this route has made it all the way
through to the customer.
So now, let's go back over to router 5.
And we're going to take a look at this rather unique way
to leak the routes between the VRFs called route replication.
Route replication was actually designed
to be part of easy virtual network or EVN.
EVN is pretty much dead.
We don't really see it in use too much anymore.
However, we still have the route replicate feature.
So let's take a look at how this works.
We'll go back into configuration mode.
We're still going to need a prefix list.
So let's call this prefix list underscore route replicate
from--
and we'll just call this A1 since the name
is getting a little long.
It's going to be coming from the customer A1 VRF.
And we'll simply say to permit router 8 to loopback.
Once again, we're going to need a route map.
We'll follow the same naming convention,
and we'll tell it to match our address.
So that takes care of our prefix list and our route map.
Then, we go into the customer B VRF,
into the address family IPv4, and we type route-replicate.
And the first thing we have to configure
is what VRF this route is coming from.
So it's going to be coming from the VRF customer A1.
It wants to know if it's unicast or multicast,
so we'll say unicast.
Then, it's going to want to know what routing protocol
is coming from.
Well, this route is originating in OSPF,
specifically process 101.
That's the OSPF process for customer A1.
If we want, we could just hit Enter right now,
and it would bring in all the routes.
So technically, we didn't need a route map,
but we did it, so we could just do this one prefix.
So we'll go ahead and apply our route map.
We'll exit configuration, and we will
have to clear the routing table for customer B
to get this to populate.
So we'll say, clear IP route for the VRF customer B, all routes.
So now, if we look at the routing table for customer B,
notice that we have this OSPF route with a plus.
And if we look up at our legend, the plus
is for a replicated route.
And that's exactly what we just did.
We also see that it's learned this from router 8,
coming from customer A1.
So this is looking good.
But there is one caveat with replicated routes.
If we go out to the customer side,
so router 10 in this case, and we say, show
IP route, notice that network is not
making it out to the customer.
So, here's the dilemma.
If we go back to router 5, we have a question here.
The question is, how do we get this route
into BGP, which is the CEPE that we're running with router 10?
Now, you might think to yourself,
well, it's showing up here as an OSPF route,
so why don't we just redistribute OSPF into BGP?
That's a good thought.
But when you redistribute OSPF into BGP,
you have to give it a process ID.
What process ID are you going to give it?
If you try to give it to 101, that's for a different VRF.
There's no process ID or OSPF identifier associated
with this particular route.
It also doesn't work to do a redistribute connected,
and it also doesn't work to try to inject it into BGP, even
with a network statement.
The network statement doesn't consider that route
to be in the routing table for the purposes of route
injection.
So I never say never, but I'm not
aware of any way to get this route into BGP to send it
to the customer.
And that was really never its intention anyway.
So it's not too surprising that there's not an obvious method
to do that.
The idea here is the customer has a different route
to get to the service provider.
Here's a big hint--
probably a default route to get to the service provider.
And then the service provider is the one
that has the more specific routes that have been
replicated between the VRFs.
So one possible solution to this problem
would be to have a default route on router 10.
Now, we could either go to router 10
and give it a static default route, pointing to the service
provider, or we could just have the service provider here,
generate a default route for router 10.
So let's go ahead and do that.
Let's have router 5 generate a default
route going to router 10.
So we'll go back into configuration mode into router
BGP 100, into the address family IPv4 unicast for the VRF
customer B. And for the neighbor 192.168.51.10,
we will do a default originate.
We'll exit configuration, and let's go over to router 10.
So let's do our show IP route here again.
And now, we have a default route, pointing to router 5.
So let's think about where we are.
Router 10 has a default route pointing
to its VRF on router 5.
The VRF for customer B on router 5
has a replicated route for router 8 loopback
to go to the other VRF.
That VRF, of course, has customer A's route
because it's had it the whole time.
And going the other way, we're using our export map
to get the route from customer B's VRF into customer A's VRF,
so router 8 has the route to get to router 10's loopback.
So since we have routes both directions
using different methods, but we have routes both directions.
That means we should have connectivity.
Let's give it a test.
Let's do a a trace to 10.8.8.8.8,
sourcing it from our own loopback.
And we see it's not a very far trip.
It goes to router 5, goes directly to router 8,
but it's definitely working.
So our leaking of these routes between the customers
is working exactly as we intended.
So in this video, we looked at how
to leak routes between VR apps for our customers.
We saw how we could do this with either an export map,
or we could do this with route replication,
specifically on IOS XE.
The preferred choice, of course, would normally
be the export map.
That is what they're intended for.
And route replicate is an older feature,
but, again, it is available if we need
to use it for whatever reason.
The next thing we want to look at
is doing conditional label advertisement.
Maybe we don't always need a label
for every prefix in the routing table.
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.