Here is our topology.
We have a fairly simple representation of a provider
network here.
This is essentially a small snippet of what we would see
within an MPLS provider network.
You can see that in the center we have an MPLS core.
And at the edges of that core, we have two provider edge routers
labeled PE1 and PE2.
These, of course, sit at the edge of the MPLS core network and connect
out to our customer sites as we see here.
And those all lie within Autonomous System 65,000.
We also have four customer edge routers labeled CE-A1,
CE-A2, CE-B1, and CE-B2.
So each of our provider edge routers has a customer A site and
a customer B site. Each individual customer having two sites
in this network. We're going to configure an MPLS Layer 3
VPN for VRF-aware routing, where we'll implement separate VRFs
for each of these customers.
Let's start on our PE1 router, our provider edge router and let's
say show mpls interfaces.
And you'll notice that we have our gig 0/2 interface
configured for MPLS,
which is connected into our provider backbone or
our MPLS Core.
If we say show mpls ldp neighbor, you can see we do have a
valid neighborship, as we would expect.
We can also say show IP OSPF neighbor.
And we're also going to see an OSPF adjacency with one of
those MPLS Core routers.
So this tells us that we have OSPF configured as an IGP on
our provider network,
and we have MPLS configured as well.
So with our provider edge devices configured for MPLS and with a
valid IGP in place in our provider network,
we're ready to begin creating and designing our customer VRFs.
Again,
these are going to be configured on the PE routers, and the interfaces
connecting to our customer sites will be assigned
into those VRFs,
which our topology on the screen indicates is going to be gig 0/0
and 0/1 on each of those routers.
So still on PE1, on our first provider edge router,
let's go ahead and create our VRFs.
Let's go under global configuration mode
and we can say IP VRF followed by the name that we want
this VRF to have.
So I'm going to name our customer A VRF simply Cust-A.
The next thing we need to do is to indicate a route distinguisher.
A route distinguisher is a way that we distinguish one
VRF from another,
and this very simply is a unique number that's going to be
prepended to each route within the VRF so that ownership
can be identified.
So in our case, we're going to create a couple of different route
distinguisher; one to identify customer A VRF traffic and
the other for customer B VRF traffic.
We do that by saying rd, followed by the actual route
distinguisher. And if we look at contextual help,
we can see the format options for that.
Now, whatever you choose, it really doesn't matter.
It's actually just up to your own preference because this
is mostly cosmetic.
I'm going to use the first format that we see indicated here,
which is a two-byte autonomous system number,
followed by a four-byte custom identifier value.
So in my case, I'm going to make the route distinguisher for the
customer A VRF 65000:1.
We also need to specify a route target,
which is the way that we indicate which routes are going to be
imported or exported with a VRF.
So let's say route-target.
And if we look at contextual help, you can see that we have the
options listed for import, export, or for both.
So we can choose which one of these we want
specifically.
In my case, I'm just going to use the both keyword to take care of
both importing and exporting prefixes.
And I'm going to give this a similarly-formatted
identifier here.
Now you can make this exactly the same as your route distinguisher
value.
And for simplicity, I typically do that.
But just know that it doesn't have to be the same.
You can give that a different identifier if you choose to do so.
Again, in my case, I'm going to keep it the same, 65000:1.
So let's also create a VRF for customer B as well.
Let's say IP VRF and I'll name that Cust-B.
I want to create a route distinguisher. This time I'll
make that 65000:2.
Again,
we want that to be unique from our customer A route distinguisher.
And then let's say route-target both.
Again, I'm going to use the same identifier, 65000:2.
So with that in place, let's go to our other provider
edge router, PE2.
And we're going to do something fairly similar here.
We want to create our VRFs on this router.
We'll do that a little bit quicker this time since we've already
discussed the reasoning behind what we're doing.
So we'll say ip vrf Cust-A, route distinguisher,
65000:1.
Route target,
both,
65000:1.
Let's also create a VRF for customer B.
Our route
distinguisher
65000:2.
Route target,
both,
65000:2.
So now we have our VRFs created.
The next thing we need to do is to assign the customer-facing
interfaces into each VRF.
So back on PE1, let's go under interface gig 0/0,
which you can see in our topology is facing the customer A
network on this router, the CE-A1 router and let's
say IP VRF forwarding.
And we will follow that with the name of the VRF,
which in our case is Cust-A.
Now notice when we do this, we have a message saying that the
interface IP address has been removed.
This is the expected behavior.
So we do need to reapply the IP address to this interface.
Now I'll also say that there are some versions of IOS that do not
have this warning message.
So this is something you want to especially be aware of if you're
using an older IOS version.
In any event, let's reconfigure that IP address,
let's say IP address.
And you can see from the topology, that should be 10.0.0.2 with
a /30 subnet mask.
So with that back in place, let's do the same
now for our customer B VRF.
We want to do that under interface gig 0/1 which is connecting
out to our customer B site.
And we'll say ip vrf Cust-B.
And actually, I left out the forwarding command, ip vrf
forwarding Cust-B.
And actually, before I do that, I have to go back because that
actually placed me under VRF configuration mode.
I don't want to do that.
So we'll go under interface gig 0/1.
We'll say ip vrf forwarding Cust-B, it's going to remove
our IP address.
So let's put that back in place, say IP address.
And this needs to be 20.0.0.2 with a /30 subnet mask.
Let's go over to PE2 and do the same thing.
Let's go under interface gig 0/0, IP VRF forwarding,
Cust-A. It's going to remove our IP address,
so we'll put that back in place.
IP address 30.0.0.2,
/30 subnet mask.
And now interface gig 0/1, ip vrf forwarding Cust-B.
Reconfigure our IP address 40.0.0.2 with a
/30 subnet mask.
If we break out of here and we say show
IP VRF interfaces, we can verify which interfaces
we've added into each VRF instance.
You see that interface gig 0/0 is associated with customer A
and 0/1 is associated with the customer B VRF.
Let's do the same on PE1. Show IP
VRF interfaces and gig 0/0 is with customer A,
0/1 is with customer B, so that's good.
Now one thing I'll point out is that if we try to ping
one of our routers.
So for example, we should be able to ping the
CE-A1 router at 10.0.0.1.
But if we try to do that, that's going to fail.
And that's because we've added these interfaces into our VRFs.
So we'll have to explicitly state which VRF we want to use when
we're trying to ping a device.
So we would need to say ping VRF, the name of the VRF,
which is Cust-A 10.0.0.1.
And this time we do get a success message.
Now it's time to take care of our multi-protocol BGP configuration.
And that's going to allow us to advertise our VRF routes between
our two provider edge routers.
So MPBGP is only going to run on the PE routers themselves.
The provider routers in the MPLS Core,
they'll be using their own IGP and MPLS to take care of all
of that traffic there.
And likewise, the customer edge routers will also have no
knowledge of routes outside of their own VRF.
So still here on PE1, let me clear off a little
bit of space.
And this is going to be a fairly basic MPBGP configuration.
So let's go under global configuration mode.
We'll go under our BGP Autonomous System number which is 65000.
And we'll say neighbor.
And you can see in the topology, the loopback address on the
PE2 router is 3.3.3.3.
So we'll use that.
We'll say remote-as 65000.
And I'm also going to say neighbor 3.3.3.3
update-source to loopback 0
to set the source of my packets as the loopback interface.
Now in order to carry our prefixes,
remember now we have the route distinguisher prepended to the
front of those prefixes, as we discussed earlier.
So in order to do that, we need to use an address family
and specifically, a VPN version 4 address family in order to
carry these longer than normal routes.
So let's say address-family.
And the option that we want to use under here is VPN version 4,
which will support our VRF route, distinguisher and IP prefixes.
When we hit "Enter", we're now under Address Family Configuration mode.
So let's activate our neighbor by saying neighbor 3.3.3.3
activate.
Now let's go to PE2 and finish up this configuration on that side.
Clear off a little bit of space.
We'll go under our BGP autonomous system number 65000.
We'll say neighbor.
You can see the loopback for PE1,
it's 2.2.2.2.
Remote-as 65000.
Neighbor 2.2.2.2.
Update-source
to
loopback zero.
You can see that we have a BGP adjacency, neighbor 2.2.2.2 is up.
So that's a good sign.
Let's say address-family VPN version 4.
And now we want to say neighbor 2.2.2.2
activate.
We do see our BGP adjacency reset because of the address
family configuration.
But we now see that we are back into the up state.
So that's good.
We have an adjacency formed.
If we break out of here, a little different than our normal
BGP show command.
We want to say show bgp vpnv4 unicast all summary.
And here we see our neighborship with the 2.2.2 router,
which is PE1.
Next, we want to configure the route exchange between our
customer edge routers and our provider edge routers.
This is going to allow us to exchange routes between the
customer and the provider.
Now we could use BGP,
we could use RIP, EIGRP, whatever we prefer between the customer
and provider edge devices.
In this case, I'm just going to use OSPF to exchange those routes.
So first let's go to CE-A1.
That's our first customer A site.
And let's do a quick show run pipe two section router OSPF.
I do want to show you what we currently have in place on all
of our customer routers.
And here, we're going to see that we have OSPF process 1
and we're advertising the local loopback address into OSPF.
We're also advertising the network that is attached to the PE router.
And we're advertising our host subnet, the 172.16.1.0/24
network.
So now let's configure OSPF on our provider edge routers.
Back on PE1.
Let's break out of here and clear off a little room.
And we want to create an OSPF process for each of our customer
VRFs that we're using on this router.
Remember, we already have process ID1 running on our provider
edge router as the IGP for the provider network.
And we can verify this by saying show run pipe two section
router OSPF.
And this is going to show us that we have OSPF process 1 running.
Again, this is being used as an IGP for our provider network.
So when we create these two new OSPF processes for our VRFs,
I want to start with number two instead.
So let me go under global configuration mode.
And I want to say router OSPF process ID 2.
And if we look at contextual help, you'll see that we can associate
this with a particular VRF.
So let's do that.
Let's say VRF,
and I'll do customer A first.
And now let's add the network that's connecting us to our
customer A edge router.
Let's say network 10.0.0.0.0.0.0.03 wildcard mask.
And we'll add that into area 0.
And we should see an adjacency form for this very shortly.
We do see that.
So that's another good sign.
Now let's create our other OSPF process for the customer B VRF.
We'll say router OSPF 3, VRF customer B,
and we want to say network 20.0.0.0.
Same wildcard mask, also into area 0.
And we should see a second adjacency form here
as well shortly.
And we did just see that happen.
So that's great.
Let's go to our PE2 router, our other provider edge router,
and we're going to do basically the same thing.
Let's go under global configuration mode.
We'll say router OSPF 2 VRF customer A.
We want to say network 30.0.0.0 with a 0.0.0.03
wildcard mask into area 0.
Now we'll create our OSPF 3 process for VRF customer B,
network 40.0.0.0,
the /30 wildcard mask and we'll say area 0.
We already saw one OSPF adjacency form.
We should see the second one soon.
And we did just see that in our console.
So we're almost there.
Our MPLS backbone is up and running,
our customer edge routers are sending routes to the provider
edge routers within separate VRFs.
So now the last thing we need to do is to redistribute
this into BGP.
Once we do that, this is going to allow our customer edge routes in
each VRF to be transported across the provider network between
our two provider sites, in other words,
between PE1 and PE2.
If you're familiar with route redistribution,
this is going to be really straightforward.
So let's go back to our PE1 router.
And we'll clear off a little space and let's first run the show
bgp vpnv4 unicast vrf Cust-A.
And you'll notice this output is blank.
If we do that for customer B, we also have a blank output.
This means we don't have any VPN version 4 routes at the moment.
Once we redistribute OSPF then we should have some routes
listed in this output.
So let's go under global configuration mode, router
BGP 65000.
And again, a really simple redistribute process that
we're going to use here.
Let's go under address-family IP version 4 VRF, Cust-A, and
we'll say redistribute OSPF.
And remember our customer A VRF is associated with OSPF process 2.
So we'll hit "Enter" for that.
And we'll do the exact same thing for customer B and we'll
redistribute OSPF process 3.
Now let's break out of here
and let's run that show command that we used earlier.
Now you'll notice, for customer B, we do have some routes learned
from the customer sites.
Let's do that for customer A as well.
And we're also seeing routes there.
That's great.
We are only seeing our CE-A1 routes and our CE-B1 routes.
Of course, we haven't configured redistribution on the
other site yet.
So let's go over and do that.
And then we should see routes from all of our customer sites.
That should give us a complete look at the network.
So let's clear off a little space here.
We'll go under global configuration mode on
PE2 router BGP 65000
address-family,
IP version 4, VRF Cust-A.
And we'll redistribute OSPF process 2 into that.
And for the VRF customer B address family, we'll redistribute
OSPF process 3.
Let's break out of here
and let's run that same show command that we used
on PE1, show IP
BGP VPN version 4 VRF Cust-A.
And now we're seeing networks from both of our customer
A sites, CE-A1 and CE-A2.
If we do the same for customer B,
we should see a similar story.
And we do.
We see routes from both of our customer B sites.
So that's exactly what we want to see.
We also want to redistribute these in the opposite direction as well.
We want to redistribute from BGP into the customer OSPF processes.
So back on PE1, let's go under router OSPF 2 which is
associated with customer A,
and we'll say redistribute BGP 65000 subnets into that.
And then router OSPF 3, which is associated with customer B.
And we'll do the same thing for that. Back on PE2,
we'll do the exact same thing.
Router OSPF 2,
redistribute BGP 65000
subnets
for OSPF 3.
Redistribute there as well.
Okay. Now we've come a long, long way.
That's a lot of commands, a lot of things going on.
Let's confirm everything.
We should now have end-to-end connectivity between our
customer edge routers.
So let's go on CE-A1.
We'll clear off a little space.
So theoretically, we should be able to ping the other customer A
site, CE-A2 at 6.6.6.6.
That's the loopback address on that router.
If we try to ping that, we are successful.
That works.
So that's great.
Now if we say show IP route,
it looks as though we have a complete routing table
for our customer A
VRF.
We see both the 172.16.1.0/24 network represented,
and the 2.0/24 network represented as well.
One last thing,
let's run a traceroute.
So let's traceroute to our other customer A site.
And we'll take a look at the path that we're taking through
the network.
You can see our first hop is 10.0.0.2,
which is, of course, our PE1 router.
After that, we notice some MPLS labels that are being used to
cross our provider network.
So first, we go over 50.0.0.1, which is going into our MPLS Core.
Then we see the 30.0.0.2 address which is PE2.
And then we reach our CE-A2 routers loopback address over the
gig 0/0 interface, which has the IP address
of 30.0.0.1.
So there's a lot going on here, a lot of moving pieces,
a lot to absorb.
But that's a look at how we would do full-blown VRF-aware routing,
configuring an MPLS Layer 3 VPN.