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

The Solution to the Problem of Conflicts When Routing Is Transmitted in the Network Why do we need RD value? A very straightforward example of this problem is the technology you will encounter in the CCIE exam, and if you are not familiar with the principle of RD worth, and the configuration of the RD value in the exam is deleted by mistake, then you cannot pass CCIE (EI) LAB exam, because deleting an RD value will cause some configurations to be automatically deleted. After successfully solving the problem of local routing conflicts, in the next step we need to resolve the conflicts of routing when passing through the network. Standard BGP can only handle IPv4 routing, so if different VPNs use the same IPv4 address prefix, the routing of different VPNs cannot be distinguished at the receiving end. Using the RT attribute can partially solve this problem, but it also has certain limitations. Let's analyze how to solve this problem and its limitations through RT. ■ After PE receives the routes from different VPNs, it decides which VRF the route enters according to the RT attribute, so as to ensure that the routes of different VPNs are not comparable and the operation can be carried out normally; ■ When the route is revoked, the BGP packet has no attributes, and RT certainly will not work, which will cause the same route in all VPNs to be revoked. Therefore, although RT has this function, it is not easy to use all the time. There must be a tag that can be bound to the IPv4 address to fundamentally solve this problem-we call this tag RD. RD is a mark attached to the front of the IPv4 address, and its format is shown in the figure: The type field defines two values: 0 and 1. For type 0, the manager sub-area includes 2 bytes, and the assigned value field includes 4 bytes. The manager sub-area uses an autonomous system number (ASN) to assign a value sub-area to the value space managed by the service provider. Type 0 cannot use private autonomous system numbers, which may cause conflicts. If you want to use a private autonomous system, you can use type 1. For Type 1, the manager sub-region includes 4 bytes, and the assigned value field includes 2 bytes. The manager sub-area uses IPv4 addresses and assigns value sub-areas to the value space managed by the service provider. The structure of RD is similar to RT, but they are essentially different. RT is an extended attribute of BGP routing, and RD is appended to the IPv4 address and exists as part of the address. This needs everyone's attention. The characteristics of some applications of RD are as follows: After adding RD to the IPv4 address, it becomes a VPN-IPv4 address family. In theory, it is possible to configure an RD for each VRF, but it must be guaranteed that this RD is unique globally. It is generally recommended to configure the same RD for each VPN. The VPN-IPv4 address is only used inside the service provider's network. It is added when the PE advertises the route, and it is placed in the local routing table after the PE receives the route to compare it with the route received later. The CE does not know that the VPN-IPv4 address is used. When it traverses the backbone of the provider, the VPN-IPv4 address is not carried in the packet header of the VPN data traffic. RD is only used when the backbone network routing protocol exchanges routes. And the standard route that the PE receives from the CE is an IPv4 route. If it needs to be advertised to other PE routers, an RD needs to be added to this route. Because RD has these characteristics, if the same address exists in two VRFs, but the RD is different, then the two VRFs must not be able to visit each other, nor can indirect mutual visits. This is because the data packet does not carry RD when data is forwarded, so that when the data arrives at the destination, the PE will find the route entry to the same destination in different VRFs, resulting in incorrect forwarding. Although RD is carried in the process of routing and exchanging PE equipment, RD does not affect the routing between different VRFs and the formation of VPN. These things are handled by RT. The difference between RD and RT Features of RD In principle, the role of RD is to change the IPv4 address into a globally unique VPNv4 address. When overlapping IPv4 addresses appear in different VPNs, RD can distinguish them. The format used is usually ASN: N, and some are based on IP address formats, such as X.X.X.X: N, but the latter is not commonly used. So as long as the VPN addresses do not overlap, RD can be arbitrarily matched. According to the characteristics of the network, we use the ASN: N method and use this AS number + N (N can be arbitrarily valued). It is generally more common to use the same RD in the same VPN. VPN-sale ASN ：100 VPN-fifinance ASN ：200 VPN-manage ASN ：300 ASN is the AS number Features of RT RT plays a very obvious role in MPLS VPN. It is used to control the isolation and partial interworking of VPN. The format is the same as RD. For different VPNs, it is required to define different RT values. If there are interworking requirements, they are controlled by RT attributes, which are divided into export and import attributes. The export attribute represents an attribute that is attached when a VPN route is sent. When another PE device receives this route, the import attribute determines whether to receive or which VPN to associate with when receiving the route. So for the definition of VPN, if the three VPNs do not require interworking, then: VPN-sale export=ASN ：100 import=ASN ：100 VPN-fifinance export=ASN ：200 import=ASN ：200 VPN-manage export=ASN ：300 import=ASN ：300   Conclusion: In the chapter <mpls vpn architecture-3>, we will talk about the third problem of traditional VPNs-packet forwarding problem. Even if the routing table conflict is successfully resolved, when the PE receives an IP packet , How can it know which VPN to send to? Because the only information available in the IP header is the destination address. This address may exist in many VPNs. SPOTO aims to help all candidates to prepare and pass Cisco CCNA, CCNP, CCIE Lab, CISSP, CISA, CISM, PMP, AWS and other IT exams in the first try. Hurry up to contact us! Related Articles: 1. MPLS VPN Architecture-1 2. MPLS VPN Architecture-2