When we left off last time, we were about to examine how MPLS might solve the three major problems that must be overcome in order to use routers within a WAN provider’s cloud. Those three problems are:
- Multiple routing tables in RAM
- Excessive latency
- Address-space collisions
Refer to Figure 1 for an example topology. Note that there are two customers, “A” and “B”, each with three sites, and that they have overlapping IPv4 address space:
The first problem we had to deal with was the amount of RAM required to support the routing tables. As we discussed last time, with MPLS, the PE routers need only the routes for the customers with which they are directly involved, and the P routers do not need any customer routes whatsoever, IPv4 or otherwise. All the P routers need is enough information to get the packets to the proper PE, and we’re using labels for that. The fact that we are shielding the PE and P routers from having to know all of the customer routes means that we’re spending less money on RAM, which solves the first of our three problems.
The second problem is latency. As previously discussed, IPv4 routers perform multiple operations on the IP header, but since the P routers are not even looking at the IP header (they’re just doing label swaps), things happen more quickly. Also, modern high-performance routers use ASICs (Application-Specific Integrated Circuits) to do the packet forwarding, which offers very high throughput at a reasonable cost. By using label switching and ASICs we’ve reduced the latency at each hop through the WAN core, so we’ve just solved the second problem.
Finally, there’s the issue of overlapping address space. Since the P routers don’t know any of the customer routers, it’s not an issue for them, but what about the PE’s? To fix this, we need another trick. What we’ll do is put a separate routing table in each PE for each customer to which it is directly attached. Looking back at Figure 1, we can see that PE2 has an attachment to Customer A, but not to Customer B. Thus, PE2 needs a routing table for A, but not for B. PE1, on the other hand, needs the routing tables for both A and B.
In the Cisco world, a per-customer routing table is called a “VRF” (Virtual Routing and Forwarding). Thus, PE1 will have VRFs for Customer A and Customer B, while PE2 will have a VRF for Customer A, and PE3 a VRF for Customer B, etc. Now, if we had a mechanism to advertise routes from a particular customer’s VRF in one PE to the corresponding customer’s VRF in another PE (and we do, it’s called MP-BGP, which we’ll discuss later), we’d have separation between the customers, each into their own Layer-3 VPN (Virtual Private Network). Using Layer-3 MPLS VPN’s, we’ve just solved the problem of Layer-3 address space collisions between customers.
Because the CE and the PE are both routers (Layer-3 devices), what we’re doing here with MPLS is referred to as a “peer-to-peer” VPN. This is different from the “overlay” VPN we built with Frame Relay, where the CE was a router (Layer-3), and the WAN cloud was Layer-2.
Having dealt with our three show-stopper issues, we’re making good progress. In our next installment, we’ll see what happens to data packets as they cross our MPLS cloud.
