OSPF
VRF Lite - VRFs without MPLS
MPLS VRFs are both a popular and widely advertised solution for provider VPNs and for segregating traffic through a backbone network, and they provide and rely on a few features to sell well
- Segmentation of the network traffic from different client devices on both sides of a cloud, usually a provider cloud;
- The option of keeping the clients routing information intact while carrying it through the cloud to another client device;
- The option for the provider to carry several client routing tables through its cloud in parallel, even if they contain overlapping address spaces, including overlapping RFC1918 addressing;
The traditional solution for such a situation, based on MPLS VPNs with separate VRF instances for each client, provides all of the features mentioned above, on the basis of a few technical items:
- A routing relationship between the client (Customer Edge, aka CE) router and the border router of the provider - Provider Edge aka PE router, using the clients routing protocol of choice ;
- The advertisement of all client networks over this routing relationship, just in the same way as if the PE router were part of the client network itself ;
- The existence of at least one VRF instance per client;
- Marking on behalf of the PE device of all client routes with a specific Route Distinguisher, aka RD tag, thus forming the so-called VPNv4 address;
- Redistribution, done by the PE device, of all client routes from the client routing protocol of choice into MP-iBGP, running only between the PE devices on both sides of the provider cloud;
- The existence of a stable IGP, sustaining the internal routing in the provider cloud, and consequently the MPLS core and MP-iBGP;
- The existence of a stable and scalable MPLS core;
All this is great if you are an ISP having a ready and stable MPLS core. However, if you are trying to develop a custom solution for your specific corporate network needs, there are a few challengfes you will face in terms of MPLS VPNs. Most of these challenges are related to device resource planning:
- You need 3 routing protocols on every PE device in your network (protocol that the client is running, MP-iBGP and a separate internal routing protocol to hold your own core network together);
- The PE devices need to be powerful and reliable enough to run and scale the 3 routing protocols needed, as well as the required number of VRFs or parallel routing tables;
- The core MPLS routers need to be powerful and scalable enough themselves;;
What the VRF Lite feature can offer is VRF functionality without the need for MPLS and its inherent complexity and resource usage, and without the need of multiple routing protocols on the PE devices. This way we can successfully carry several routing tables in parallel through a cloud without having MPLS inside it.
Using VRFs with MPLS implies that the segregation of the different client routing tables is achieved through using a separate protocol between the PE devices, carryng these client routing tables, tagged accordingly with the right RD tag. In order to enable the same segregation of routing tables with VRF Lite, that is without MPLS, we need to have separate connectivity over which to run multiple routing neighborships between our devices, with each neighborship only carrying a single VRFs routing table.
We can use the following two lab scenarios to illustrate the differences between the two VRF configurations.
Българска версия
Chat
| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| « Nov | ||||||
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | |||
Recent Posts
Recent Comments
- ravi on VRF Lite - VRFs without MPLS
- Thiyagu on BGP RIB-Failure