MPLS VPN Architecture-2
Solution to the problem of local routing conflict Why is there a local routing conflict problem? Traditional overlay vpn A corresponding GRE tunnel is established on the PE for each VPN user, routing information is passed between the PE and the PE, and the P device in the public network does not know the routing information of the private network. The customer completely hands over the creation and maintenance of the VPN to the service provider, with better confidentiality and security. However, different VPN users cannot share the same address space. Even if they can share, the addresses between PE and CE, and the addresses between tunnels must not be the same, and a large number of ACLs and policy routes must be used. It is not feasible in practice. So there will be local routing conflicts. 
Solutions: The solution to the problem of local routing conflicts is mainly borrowed from the dedicated PE peer-to-peer VPN model. The dedicated router has a clear division of labor, and each PE only keeps its own VPN route. P only reserves public network routes. The current idea is to integrate the functions of all these devices on one PE. 
The specific operation is to divide different VRFs on the PE device. Each VRF can be regarded as a virtual router, as if it is a dedicated PE device. The virtual router includes the following elements:
■ An independent routing table, of course, also includes an independent address space;
■ A set of interfaces belonging to this VRF, the specific VRF is judged by which interface the data packet is received from;
■ A group of routing protocols only used for this VRF.
For each PE, one or more VRFs can be maintained, while maintaining a public network routing table (also called a global routing table). Multiple VRF instances are separated and independent of each other. Compared with the complicated ACL configuration, the mechanism of multiple forwarding tables greatly simplifies the PE router to provide isolated support for each VPN routing information. What is the RT value? It is not difficult to achieve VRF local routing differentiation, but to resolve remote routing differentiation, it is necessary to use specific policy rules on the PE to coordinate the relationship between each VRF and the global routing table. This mainly refers to how the PE device distinguishes whether the received route belongs to the VPN route or the global route on the public network.
The solution is to add a specific mark to the VPN route. Different marks indicate different routes, and the PE device uses this mark to determine which VRF the route should be written to.
To solve the problem of labeling, we need to find a solution from the attributes of BGP. The routing attributes of the BGP protocol are very flexible and have excellent scalability. Recalling the various attributes of BGP, the characteristics of community attributes are most suitable for solving this problem. The community attribute is an optional transitive attribute, which is mainly used to simplify the execution of policies. The group attribute indicates that a destination is a member of some destination groups, and these destinations share one or more common characteristics. In other words, the community attribute is for specific routes, and the peer groups with similar functions are for peer routers, which does not apply here. So we can solve the problems we face by transforming the attributes of the group. The function of the modified group attribute is the same as before, but in order to distinguish it from the traditional group attribute, we give it a new name-RT. In this way, the PE device can distinguish the routes of different VRFs by adding the RT attribute to the specific route entry.
The essence of RT is that each VRF expresses its own routing choices and preferences. It can be divided into two parts: Export Target and Import Target; the former indicates the attributes of the routes I sent, and the latter indicates which routes I am interested in. At the same time, the application of RT is relatively flexible. Each VRF Export Target and Import Target can be configured with multiple attributes, for example: I am interested in red or blue routes. When receiving, it is an "or" operation, and the routes of red, blue, and both colors will be accepted. This allows very flexible VPN access control. Below we illustrate the application of RT through an example analysis:
As shown in the figure, each red company's site is associated with the red VRF on the PE router. PE configures a globally unique RT (RED) for each red VRF as its input and output target. The RT will not be assigned to any other VRF as their RT (such as the blue VRF), so as to ensure that the VPN of the red company contains only the routes in its own VPN. The specific steps are as follows:■ Site-1: The route I sent is red, and I only receive the red route;
■ Site-2: The route I sent is red, and I only receive the red route;
■ Site-5: The route I sent is red, and I only receive the red route;
■ Site-3: The route I sent is blue, and I only receive the blue route;
■ Site-4: The route I sent is blue, and I only receive the blue route;
■ Site-6: The route I sent is blue, and I only receive the blue route.
In this way, only Site-1, 2, and 5 have their own routes with each other, and the two realize mutual access. The same is true for Site-3, 4, and 6. At this time, we can call Site-1, 2, 5 as VPN-A, and Site3, 4, 6 as VPN-B.
Below we make a summary of this part through a comparison between the dedicated PE method and the VRF method:
|
Compared |
Routing |
Receive route |
|
Special PE method |
On the routers belonging to a specific VPN, use the community attribute of BGP to mark the routes of this VPN with special tags. And send the route to the P router |
Receive all routes on the P router and send them to specific VPN PE devices according to the community attribute in the route |
|
VPF method |
In a VPF, the RT export rules are used when advertising routes. Send directly to other PE equipment |
On the PE at the receiving end, receive all routes and check according to the RT import rules configured for each VPN. If it matches the RT attribute in the route, add the route to the corresponding VPN |
Conclusion In this article, <mpls vpn architecture-3> I will introduce the second problem of traditional VPNs-the problem of routing propagation in the network. Two identical routes are spread in the network.
How to distinguish the receiver; if you want to know what the RD value is, be sure to check it out
If you desire to pass the Cisco exams and looking for the most reliable and clear to understand the material so, now it is very easy for you to get it at SPOTO. We are presenting you here the most up-to-date questions & answers of Cisco exams, accurate according to the updated exam. Note: if you are interested in this topic, and you can follow SPOTO. we will update more realted articles.
Related Article: MPLS VPN Architecture-1
- Which would be good for a Fresher - CCIE Routing and Switching or CCIE Security?
- Mastering Layer 3 Connectivity Troubleshooting for the CCIE Data Center Certification
- Weekly Report-SPOTO Exam Dump Info & Passing News from Sep.28th to Oct.4th, 2020
- New CCNP Certifications Rundown
- How to Pass the CCNA Exam: Tips from an IT Certified Expert?