From the course: Cisco CCNP Enterprise: ENARSI (300-410) Cert Prep

MPLS Layer 3 VPN

From the course: Cisco CCNP Enterprise: ENARSI (300-410) Cert Prep

Start my 1-month free trial Buy for my team

MPLS Layer 3 VPN

“

We have a service provider cloud containing two internal routers labeled P1 and P2. And at the edge of this cloud, we, of course, have provider edge routers labeled P1 and P2. These each connect into our customer edge routers. And we have four of those at the edge of our customer clouds. You can see we have two companies with two different locations. We have customer A, site 1, and site 2. And we have customer B with site 1 and site 2. Now the entire reason we use VPNs are that they allow us to emulate point-to-point connections so that we don't require a dedicated link. So this is much more cost effective and scalable. Remember, MPLS uses labels to make forwarding decisions rather than IP information. Within this topology. we have an IGP running between all of our provider routers. Now that could be OSPF, EIGRP, or they could even be static routes. But the goal is to have full connectivity between our entire provider cloud. With MPLS, let's say we look at customer A here who has two sites. Let's suppose that both of these sites are using a local network of 192.168.0.0/24. So that could potentially present a problem. And what we want to do to correct that is to define some VRF instances for each customer. VRFs are virtual forwarding instances, and they allow us to have multiple instances of a routing table on a router. So for example, on our PE1 router, we could have multiple routing tables dedicated to each customer. On our PE routers, you can see that if we create a VRF for each site, that's going to allow us to separate our customer traffic. So customer A and B here would have two different VRF instances, and PE1 would maintain two separate routing tables. We could have one named VRF customer A and VRF customer B. To share information between our provider edge routers, we would use BGP to do that. When PE1 receives an advertisement from customer A through a routing protocol or through a static route, the PE1 router will use Customer A's VRF to store that in its dedicated routing table for the customer. The PE will then redistribute everything into BGP and advertise that to our other iBGP peer, which is of course PE2 in this topology. Now again, the problem is, customer A has two sites using the same local network address space. So we need to make all of our learned prefixes unique. And this is where the concept of a route distinguisher comes in. Since they're both using the 192.168.0.0/24 network internally, we need a way to keep track of those routes. We do that with a unique number identifier called a route distinguisher or an RD in the command line. This is an eight-byte field that can really be any number you want, but typically, most people follow the convention of the autonomous system number followed by the site number, and those are separated by a colon. So for customer A, site 1, we might make that 100:1. This route distinguisher is combined with the prefix and that makes up what we call a VPNv4 route. And these will be transmitted using multi-protocol BGP or MPBGP. Now we have a way to separate the prefixes of our customers and their respective sites. So we can create rd100:1 for customer A, site 1 and we can create rd 200:1 for customer B, site 1. So even if these two sites are using the same prefix, we'll have a different distinguisher, and these will have unique VPN version 4 routes advertised over MPBGP. Now additionally, for each VRF, we need to designate a route target, that's route-target in the command line. This is another eight-byte unique identifier. When PE2 receives these two VPN routes, how will it know the correct VRF in which to place the route? And that's why we use route targets. We designate the route target inside of our MPBGP message so that it gets imported correctly on the other neighboring edge router. It's common to set these to the same value as the route distinguisher, but that's certainly not required. You can set those to any number you like. So if we set the route targets also to 100:1 and 200:1, PE1 will be able to place these routes into the correct VRF. So again, just to reiterate, both PE routers would be configured with a VRF for each customer. Let's take customer A, for example, and we can see each of these PEs, the provider edge routers, have a VRF called customer A and customer B. When PE1 receives a prefix from customer A, site 1, it will add a route distinguisher and a route target that we configure. Let's suppose both of those are 100:1, since we're using customer A, site 1. PE1 will add our RD and RT to all of the VPN version 4 routes for VRF customer A. This unique VPN version 4 route is advertised using multi-protocol BGP, which allows PE1 to advertise the VPN version 4 route to PE2. PE2 is configured to export all VPN version 4 routes containing route target 100:1 into its VRF for customer A, which is also named the same as the VRF from PE1. This is then redistributed into the VRF, which allows the customer A, site 2 router on the other side of our topology to learn the prefix. So there are a lot of moving parts here, and a lot of the combinations of the technologies and protocols that we've been looking at throughout this series. But again, you simply need to understand the function of a Layer 3 MPLS VPN and know the important components used to configure that. MPLS VPNs give us improved performance and traffic control, and they also add an additional layer of security that isn't possible over the normal public Internet. It also helps to reduce bandwidth requirements and allows you to much more easily scale your network.

Contents