Mpls vpn Principle advanced Edition

Mpls vpn is a layer-3 VPN. It is also the most widely implemented MPLS technology. The mpls vpn service model is included here. I believe you have a better understanding of the MPLS VPN architecture:
 
The above is a core application model of mpls vpn. Both P and PE run MPLS. Therefore, the selection of PE and P devices requires that these devices support MPLS Label Distribution and forwarding of MPLS packets.
The following is a summary of each technical structure of mpls vpn technology: virtual route forwarding VRF-virtual routing forwardingVRF is an instance of VPN routing and forwarding. each Independent VRF has an independent route table. This concept is very important. Because the routes on the PE router need to be isolated from each other to ensure the private nature of each user's VPN, each VPN should have its own route table. This private route table is called a VRF route table. There is no difference between the VRF route table and the global route table of cisco IOS, but this route table is only valid for a VRF and is completely isolated from other route tables. let's take a look at the figure.
 
RD --- route distinguish routes distinguish RD to solve address conflicts. VPNV4 prefix = RD + IPv4 prefix. for the above figure, I will often encounter A problem in real life. There are two companies, Company A and Company B. The private network addresses of everyone are 192.168.0.0/16, at this time, the routes of the two companies are sent to the PE router. How does the PE router know that Company A's 192.168.0.1 to 10.1.1.1 should be sent to vrf, but should Company B's 192.168.0.1 be sent to vrf B?
This problem was solved by RD. RD is a 64-bit field used to ensure the uniqueness of these prefixes when the MP-BGP carries VRF prefixes. RD does not indicate which VRF the prefix belongs to. The RD function is not a VPN identifier, because in some more complex environments, a VPN may have multiple RD.
Each VRF instance on the PE router must be assigned an RD. the format is ASN: nn or IP address: NN. nn indicates a number. if an IPv4 prefix is 10.1.1.0/24 and RD is, the prefix of VPNv4 is: 1: 1: 10.1.1.0/24. this ensures its uniqueness. RD is the VRF route identifier. It is irrelevant to the MPLS core network. Therefore, the simple memory mode is that RD is the identifier of a VRF route. RD is the route destination of the MPLS core network.
RT ---- Route target if RD is only used to mark the VPN, communication between different VPN scenarios may fail. A location of Company A cannot communicate with A location of Company B because their RD does not match. It enables strategic mutual access between different companies, known as external communication. Communication between a vrf is called internal communication. Internal communication is relatively simple.
The unique identifier of VRF is RD. the routing transmission from the core network PE to the PE uses the Route target. a RT is a BGP scaling group that explains which routes need to be injected into the VRF from the MP-BGP. RT atmosphere Route target export and Route target import.
Route target export: indicates that the output VPNv4 Route has received an additional BGP Extension Group. route target import: The Vpnv4 Route check received from the MP-BGP can match the scaling group. if a matching RT is found, the prefix is added to the VRF routing table as an IPv4 route. Otherwise, the prefix is rejected. RT Configuration:
It is described that When configuring mpls vpn, it is quite easy to communicate with the location of other VPNs, but to communicate internally for a VRF. However, if you want the location of a VPN to communicate with the location of another VPN, You need to configure RT correctly. Here we need a more informative instance to break down this knowledge point:
 
There are two customers. cust-one and cust-two. Of course, the basic requirement is very simple. Communication is required between the same vrf, while location A of cust-one needs to communicate with location A of cust-two. So how can we use RT for configuration?
 
The RT export corresponding to the local PE is the RT import to the peer. vice versa, so that the route can be correctly introduced to the vrf to be introduced. Of course, this is definitely symmetric. I will not send a route, but the peer will not give it to me. There is no problem with the configuration, but it does not make sense for the actual production network. There is no one-way communication application.
 
As you can see above, the extended group property RT in this instance is. Because both import and export are, only one is shown here. If the two configurations are different, they will be displayed separately:
 
In mpls vpn, how does VPNv4 route spread?
 
This figure fully illustrates the propagation process. First, VPN1 locationA and CE forward the received customer traffic to PE. of course, IGP or EBGP can be used between CE and PE to advertise pure IPv4 routing. When PE vrf receives the route, IPv4 route is injected into the vrf route table, IPv4 route is re-distributed to the MP-BGP, RD and RT are added, the backbone network PE and PE advertise the vpnv4 route with labels and RTS through IBGP, and through RT, we can know which peer PE-2 should be injected into the VRF, then, remove the RD from the VPNv4 route. Finally, the ipv4 route is advertised to CE2. that is, the CE of location B through IGP or EBGP.
In fact the entire process is: IPv4-& gt; plus RD/RT -- & gt; Re-step to the MP-BGP -- & gt; notice to the peer PE MP-BGP -- & gt; inject peer PE vrf route table -- & gt; remove RD/RT -- & gt; advertise CE to vrf connection. finally, the communication is completed. Of course, only RD/RT is mentioned here. In fact, in the real transmission process, the backbone network also needs to distribute tags to establish FEC, then, the traffic is transmitted step by step through the tag forwarding table.
We emphasize the importance of RT and RD, but RD and RT only work during route maintenance. In actual MPLS packet forwarding, there is no such information, but only the tag information will be included. here we need to clarify the concept. In many cases, this concept will be mixed up. Okay. Speaking of this, RT is the Hub-and-Spoke model when the data is sent to PE.
There is an application model called the Hub-and-spoke model. users do not want to have full interconnection between their sites. A typical application environment is that the company has one HQ and many branches, such as the banking system. All branch data streams are directly uploaded to the Headquarters server, and the latest data is directly downloaded from the Headquarters server. The branches and branches of the Bank cannot communicate with each other. This requirement is based on security.
However, the following conditions are required for cross-through in mpls vpn: ■ spoke (branch office) can only communicate with the hub (Headquarters. ■ The traffic from spoke to spoke must be sent to the hub (Headquarters) and then forwarded by the headquarters. (Of course, it is forwarded by the CE router at the headquarters, which can control data traffic well.) to achieve this, the following parameters must be adhered to: two different RT. two different RD. in this case, it is obviously very empty. We will use an experiment to describe it in detail:
 
It took me one afternoon to build this instance. The purpose is to verify RT to implement the hub-spoke application mode. This figure may seem too costly. I will sort it out again to see why branch 1 can only communicate with HQ, and branch 2 can only communicate with HQ, but branch 1 and branch 2 cannot communicate with each other.
 
From this figure we can see that branch-1 to the right HQ, the RT export of the PE-1 and the import of the Peer PE-3 are matched. While the RT import of the PE-1 can also match the export of the PE-3, so it can communicate with each other. PE-2 and PE-3 are the same.
Another point here is that although all of them are vrf, each RD is different. Let's review what RD is doing. Why can we continue to communicate with each other? RD is a 64-bit field used to ensure the uniqueness of these prefixes when the MP-BGP carries VRF prefixes. RD does not indicate which VRF the prefix belongs to. The RD function is not a VPN identifier, because in some more complex environments, a VPN may have multiple RD.
RD is only used to mark the customer route in VRF. If there is a duplicate route on the CE side in the MPLS backbone network, similar to 192.168.0.1, a unique identifier is required to indicate two routes with the same network segment.
This is why RD needs to be clearly indicated here. If there are no repeated network segments, in fact, the RD can be identified as the same. However, if there are repeated client routes, RD must be different. Otherwise, there is no way to transmit the routes, which may cause network problems.
Below are the core configurations in the experiment: R1-PE-1: hostname R1-PE-1ip vrf maipurd 1: 1route-target export 100: 100route-target import 100:101! Multilink bundle-name authenticatedmpls label protocol ldp! Interface Loopback0ip address 1.1.1.1 255.255.255.255! Interface FastEthernet0/0ip vrf forwarding maipuip address 13.1.1.1 255.255.255.0duplex full! Interface GigabitEthernet1/0ip address 10.1.1.1 255.255.0negotiation autompls label protocol ldpmpls ip! Interface GigabitEthernet2/0ip address 12.1.1.2 255.255.0negotiation autompls label protocol ldpmpls ip! Router ospf 1router-id 1.1.1.1log-adjacency-changesnetwork 0.0.0.0 255.255.255.255 area 0! Router bgp 65500no synchronizationbgp router-id 1.1.1.1bgp log-neighbor-route 1.1.1.2 remote-as 65500 neighbor 1.1.1.2 update-source protocol 1.1.1.2 next-hop-route 1.1.1.3 remote-as 65500 neighbor 1.1.1.3 update-source loopback0neighbor 1.1.1.3 next-hop-selfno auto-summary! Address-family vpnv4neighbor 1.1.1.2 activateneighbor 1.1.1.2 send-community extendedneighbor 1.1.1.3 activateneighbor 1.1.1.3 send-community extendedexit-address-family! Address-family ipv4 vrf maipuredistribute connectedno synchronizationexit-address-family! R2-PE-2: hostname R2-PE-2! Ip vrf maipurd 1: 2route-target export 100: 100route-target import 100:101! Multilink bundle-name authenticatedmpls label protocol ldp! Interface Loopback0ip address 1.1.1.2 255.255.255.255! Interface FastEthernet0/0ip vrf forwarding maipuip address 14.1.1.1 255.255.255.0duplex full! Interface GigabitEthernet1/0ip address 10.1.1.2 255.255.0negotiation autompls label protocol ldpmpls ip! Interface GigabitEthernet2/0ip address 11.1.1.1 255.255.0negotiation autompls label protocol ldpmpls ip! Router ospf 1router-id 1.1.1.2log-adjacency-changesnetwork 0.0.0.0 255.255.255.255 area 0! Router bgp 65500no synchronizationbgp router-id 1.1.1.2bgp log-neighbor-route 1.1.1.1 remote-as 65500 neighbor 1.1.1.1 update-source protocol 1.1.1.1 next-hop-route 1.1.1.3 remote-as 65500 neighbor 1.1.1.3 update-source loopback0neighbor 1.1.1.3 next-hop-selfno auto-summary! Address-family vpnv4neighbor 1.1.1.1 activateneighbor 1.1.1.1 send-community extendedneighbor 1.1.1.3 activateneighbor 1.1.1.3 send-community extendedexit-address-family! Address-family ipv4 vrf maipuredistribute connectedno synchronizationexit-address-family! R3-PE-3: hostname R3-PE-3ip vrf maipurd 1: 3route-target export 100: 101route-target import 100:100! Multilink bundle-name authenticatedmpls label protocol ldp! Interface Loopback0ip address 1.1.1.3 255.255.255.255! Interface FastEthernet0/0ip vrf forwarding maipuip address 16.1.1.1 255.255.255.0duplex full! Interface GigabitEthernet1/0ip address 11.1.1.2 255.255.255.0negotiation autompls label protocol ldpmpls ip! Interface GigabitEthernet2/0ip address 12.1.1.1 255.255.0negotiation autompls label protocol ldpmpls ip! Router ospf 1router-id 1.1.1.3log-adjacency-changesnetwork 0.0.0.0 255.255.255.255 area 0! Router bgp 65500no synchronizationbgp router-id 1.1.1.3bgp log-neighbor-route 1.1.1.1 remote-as 65500 neighbor 1.1.1.1 update-source protocol 1.1.1.1 next-hop-route 1.1.1.2 remote-as 65500 neighbor 1.1.1.2 update-source loopback0neighbor 1.1.1.2 next-hop-selfno auto-summary! Address-family vpnv4neighbor 1.1.1.1 activateneighbor 1.1.1.1 send-community extendedneighbor 1.1.1.2 activateneighbor 1.1.1.2 send-community extendedexit-address-family! Address-family ipv4 vrf maipuredistribute connectedno synchronizationexit-address-family! R4-CE-1: hostname R4-CE-1! Interface FastEthernet0/0ip address 13.1.1.2 255.255.255.0duplex full! Ip route 0.0.0.0 0.0.0.0 13.1.1.1R5-CE-2: hostname R5-CE-2! Interface FastEthernet0/0ip address 14.1.1.2 255.255.255.0duplex full! Ip route 0.0.0.0 0.0.0.0 14.1.1.1
R6-CE-3: hostname R6-CE-3! Interface FastEthernet0/0ip address 16.1.1.2 255.255.255.0duplex full! Ip route 0.0.0.0 0.0.0.0 16.1.1.1 finally let's take a look at the results:
From R4-CE-1 to R6-CE-3, pass.
 
From R5-CE-2 to R6-CE-3, pass.
 
However, branch 1 to branch 2 (R4-CE-1 to R5-CE-2), not reachable: