Service provider SP provides VPN connectivity between multiple sites belonging to Customers A and B, as depicted by CustA and CustB VRFs on the appropriate PE routers illustrated in Figure 14-6.
Figure 14-6. Case Study 2 Topology
Some sites belonging to Customer A and Customer B are connected into a managed CE offering provided by the service provider SP. The service provider implements multi-VRF CE to enable the same managed CE router to be used for connecting domains belonging to both Customer A and Customer B. CE1 and CE5 routers are managed CEs that run the multi-VRF CE feature and, thus, enable connectivity of both Customer A and Customer B sites into the MPLS domain using a single SP managed-CE router.
In addition, CE Routers CE2 and CE3, connecting to PE Router PE2-AS1, provide connectivity to servers that are to be selectively reachable by Customer A and Customer B domains. Figure 14-6 depicts loopback interfaces on CE2 and CE3 that are used to emulate servers attached to these CE routers. As illustrated in Figure 14-6, one server on each of these CE routers is to be made reachable to Customer A and Customer B, respectively.
The SP implements these requirement using VRF selection using source IP address in relationship to servers connected to CE2 and VRF selection using policy-based routing to enable connectivity to servers connected to CE3 for the Customer A and Customer B domains.
SP is looking for improved methods to offer shared services to customers being offered MPLS VPN services. To enable Internet access for multiple customer VPNs, the IP addressing space pertaining to Internet access needs to be unique, though possibilities of overlapping customer addresses exist between multiple VPN domains. Therefore, SP implements NAT to enable such shared services to multiple customers. The NAT Integration with MPLS VPNs feature enables the implementation of NAT on a PE router in a MPLS cloud.
In Figure 14-6, PE3-AS1 has Router ServicesCE (CE3) connected that provides shared services to both VPNs CustA and CustB, which is part of VRF Services. NAT is implemented on the Router PE3-AS1 such that CustA and CustB networks (IP addresses in the ranges 172.16.x.x and 192.168.x.x for customers A and B, respectively) can access the shared services CE after undergoing an NAT translation from the private address space to the real IP address space range of 184.108.40.206-250/27.
In redundant CE to PE connections in which the same CE is connected to multiple PE routers, like in the case of CE4-A being connected to PE4-AS1 as well as PE5-AS1 using HSRP, CE4-A has a default route pointing to the virtual IP address of the HSRP group. In addition, there are also possibilities that hosts in the customer domain might have a default gateway configured to the HSRP virtual IP address. With HSRP support for MPLS VPN, the PE routers enable the addition of ARP entries for the virtual IP address to the VRF routing table associated with the interfaces connected to the CE routers. CE4-A belonging to CustA VRF has a default route pointing to the HSRP virtual IP address 172.16.4.100/24 to reach other hosts belonging to the CustA and other domain networks.
Finally, Customer A has posed an additional requirement for the SP to support transport of multicast to enable intersite multicast traffic to enable different sites to view web training using VOD or IP/TV. Therefore, the SP supports this requirement by enabling the VRF CustA for multicast MPLS VPN support. Multicast MPLS VPN support is implemented for Customer A multi-VRF CE connected routers, namely CE1-A and CE2-A, connecting to CE1 and CE5, respectively.
Configuration of Core Devices in Case Study 2
Figure 14-7 outlines the basic configurations for the devices in the SP domain, namely PE1-AS1, PE2-AS1, PE3-AS1, PE4-AS1, and PE5-AS1. It is assumed that MPLS forwarding has been enabled on the appropriate interfaces and IP addressing performed as shown earlier in Figure 14-6. Only VRF-related definitions and configurations of IGP and MP-BGP on the PE routers are shown in Figure 14-7. Configuration of P1-AS1 involving OSPF as the IGP, as well as all interfaces enabled for MPLS forwarding, are not depicted in Figure 14-7 for brevity.
Figure 14-7. Case Study 2 Topology: SP Routers Base Configurations
Theory and Configuration of Features in Case Study 2
This section outlines the theory and configurations behind the operation of the just mentioned features.
Multi-VRF CE enables the same CE router to connect to multiple customer domains and still provide transparency of customer traffic across the MPLS backbone. The caveat with multi-VRF CE is that a dedicated interface (either physical or logical) is required per customer between the PE and CE router for the CE router to implement multi-VRF CE. With multi-VRF CE, the CE router can implement separated routing tables for different services that need to be configured on the customer. However, no label exchange occurs between the PE and the connected CE, though the CE router has VRFs configured on it. Depending on the protocol in use between PE and CE routers, the configuration of the PE and CE routers vary. The protocols currently supporting multi-VRF CE are RIPv2, OSPFv2, and BGP.
Figure 14-8 outlines the steps in the configuration of multi-VRF CE on the managed CE router connecting multiple customer domains and the attached PE router.
Figure 14-8. Multi-VRF CE Configuration Flowchart
A similar configuration is to be performed on the SP-managed CE Routers CE1 and CE5 connected to PE1-AS1 and PE2-AS1, respectively. The multi-VRF related configurations for the devices are shown in Figure 14-9. The configurations illustrate the CE1-A, CE1-B, CE2-A, and CE2-B customer routers connected to the multi-vrf CE Routers CE1 and CE5. Note that multi-VRF CE with OSPF PE-CE has been implemented in this case study and can be implemented using other protocols following the configuration flowchart shown in Figure 14-8.
Figure 14-9. Multi-VRF CE Configurations for Case Study 2
VRF Selection Based on Source IP Address and Policy-Based Routing
VRF selection based on source IP address is a method to decouple the actual interface connecting the PE and CE routers from the VPN. Therefore, a subset of IP addresses belonging to the customer domain can be associated with one VPN versus another. In traditional VPN operation and configuration, each logical or physical interface connected to a CE router is assigned as part of a VRF. With VRF selection on source IP address, this is no longer a requirement. There can be a range of IP addresses assigned to different VRFs. However, care must be taken to perform accurate IP addressing. This solution makes it lucrative to offer Internet access to a subset of users from the same customer CE attached domain. Figure 14-10 depicts the configurations to be performed on the associated CE and PE routers to enable VRF selection based on source IP address. In the case study, access to servers (simulated by loopbacks on CE router CE2) will be provided for Customer A (172.16.20.1) using the VRF selection on source IP address.
Figure 14-10. VRF Selection Based on Source IP Configuration Flowchart
The key configurations involve identification of IP address ranges that apply to a certain VPN on the PE as well as configuration of static routes pointing to those prefixes from the PE to the CE routers. In addition, the interface that will be used for VRF selection based on source IP address needs to be enabled for the feature; the VPNs that will be used on that interface also need to be defined.
VRF selection based on policy-based routing (PBR) is similar in operation and configuration to VRF selection based on source IP address. Note, however, that an interface configured for VRF selection based on source IP cannot be also configured for VRF selection based on PBR. In VRF selection based on PBR, policy routing of VPN traffic is based on match criteria. Match criteria is defined in a prefix list, in an IP access list, or based on packet length. Policy routing is defined in the route-map. The route-map is applied to the incoming interface with the ip policy route-map interface configuration command.
The flowchart for the implementation of VRF selection using PBR is shown in Figure 14-11.
Figure 14-11. VRF Selection Using PBR Configuration Flowchart
By following the steps shown in Figure 14-10 and Figure 14-11, the devices PE2-AS1, CE2, and CE3 are configured to implement VRF selection. The configurations of only PE2-AS1 shows VRF selection using source IP address in relationship to CE2 and VRF selection using PBR in relationship to CE3. Configurations of PE2-AS1 for implementing these two features on the interfaces connecting to CE2 and CE3 are illustrated separately in Figure 14-12 for clarity. Configurations do not show the IGP, MP-BGP, and VRF definitions as they are already shown in Figure 14-7.
Figure 14-12. VRF Selection Using PBR and Source IP: Configurations for Case Study 2
HSRP Integration with MPLS VPN
With HSRP support for MPLS VPN, the CE4-A router can be connected to PE Routers PE4-AS1 and PE5-AS1 and, thus, enables the addition of ARP entries for the virtual IP address to the VRF routing table associated with the interfaces connected to the CE router.
The configuration flowchart for the implementation of HSRP integration to MPLS VPN is shown in Figure 14-13.
Figure 14-13. HSRP Integration to MPLS VPN: Configuration Flowchart
HSRP integration is configured on PE4-AS1 and PE5-AS1 with a virtual IP address of 172.16.4.100. CE Router CE4-A has a static default route pointing to this VIP address. PE4-AS1 and PE5-AS1 are also configured with static VRF routes pointing to CE4-A networks. The configurations for HSRP integration are shown in Figure 14-14.
Figure 14-14. HSRP Integration to MPLS VPN: Configurations for Case Study 2
NAT Integration to MPLS VPN
NAT can be implemented to enable shared services to multiple customers. The NAT Integration with MPLS VPNs feature enables the implementation of NAT on a PE router in an MPLS cloud. Configurations for the implementation of NAT integration to MPLS VPN are only required on the PE router performing NAT integration. In the case study, this function is provided by PE Router PE3-AS1, which connects the VRFs, CustA and CustB, to the services VRF configured on PE3-AS1 after undergoing an NAT translation. The configuration flowchart for the implementation of NAT integration to MPLS VPN is shown in Figure 14-15.
Figure 14-15. NAT Integration to MPLS VPN Configuration Flowchart
The configurations for PE Router PE3-AS1 performing NAT translation for networks 172.16.x.x from CustA and 192.168.x.x from CustB are shown in Figure 14-16.
Figure 14-16. NAT Integration to MPLS VPN Configuration for Case Study 2
Multicast VPN Support over Multi-VRF CE
Multicast VPN support enables the SP to provide for Customer A's requirement of transport of multicast traffic between its sites. Multicast VPN support is configured by enabling the core VRFs needed to support multicast traffic transport with a default multicast distribution tree that transports all customer multicast frames between sites. In addition, source specific multicast (SSM) is enabled on all routers in the SP domain to enable transport of multicast information between SP domain routers.
In the case study, a source connected to CE1-A router sends multicast frames to group 220.127.116.11. PIM (protocol-independent-multicast) sparse-dense mode is configured on all interfaces in the customer and provider domains to enable transport of customer multicast traffic. A default MDT of 18.104.22.168 is configured for VRF CustA on all PE routers to enable tunneling of multicast frames between PE routers. Finally, a receiver is connected to CE5-A that joins the 22.214.171.124 group and, thus, has to receive traffic destined for the group.
The configuration flowchart for SP domain routers and CE routers has already been shown as part of Case Study 1 in Figure 14-2. In this setup, the implementation involves multicast VPN over multi-VRF CE where the multi-VRF CE has VRF definitions. However, no MDT configuration is required on the multi-VRF CE under the VRF definition to enable transport of multicast frames.
Configurations for the devices in Case Study 2 to support multicast traffic forwarding between CE1-A and CE2-A Customer A routers are illustrated in Figure 14-17.
Figure 14-17. Multicast VPN Support: Configurations for Devices in Case Study 2
Verifications for Case Study 2
Figure 14-18 shows the verifications associated with the implementation of Case Study 2. Only verifications for VRF CustA have been shown for brevity.
Figure 14-18. Verifications for Case Study 2
Final Configurations for Case Study 2
Figure 14-19, Figure 14-20, and Figure 14-21 show the final configurations for the CE and PE devices in Case Study 2.
Figure 14-19. Final Configurations for CE Routers in Case Study 2
Figure 14-20. Final Configurations for PE1-AS1, PE2-AS1, and P1-AS1 in Case Study 2
Figure 14-21. Final Configurations for PE3-AS1, PE4-AS1, and PE5-AS1 in Case Study 2
Basic MPLS Configuration
Basic MPLS VPN Overview and Configuration
PE-CE Routing Protocol-Static and RIP
PE-CE Routing Protocol-OSPF and EIGRP
Implementing BGP in MPLS VPNs
Carrier Supporting Carriers
MPLS Traffic Engineering
Implementing VPNs with Layer 2 Tunneling Protocol Version 3
Any Transport over MPLS (AToM)
Virtual Private LAN Service (VPLS)
Implementing Quality of Service in MPLS Networks
MPLS Features and Case Studies