MPLS-based Layer 3 VPNs

MPLS-based Layer 3 VPNs Overall objective The purpose of this lab is to study Layer 3 Virtual Private Networks (L3VPNs) created using MPLS and BGP. A VPN is an extension of a private network that uses a public communication infrastructure (operated by a network service provider) to interconnect a group of geographically distributed private sites. A Layer 3 VPN provides IP connectivty between VPN sites. The most common approach uses BGP to exchange VPN routes between provider edge routers and MPLS label switched paths for data transport. This approach, described in RFC 4364, "BGP/MPLS IP Virtual Private Networks" (2006), is studied in this lab. Prerequisites You should be familiar with the basic concepts and operation of MPLS and LDP (Label Distribution Protocol), intra-domain and inter-domain routing using RIPv2 and BGP, as well as MPLS-based VPNs. These topics are presented in the course material. Review them before the lab. Case study We consider the scenario shown in Figure 1. A network service provider (SP) operates an MPLS network and offers VPN services. The current task is to set up VPNs for the customers A and B. The network of each of these customers consists of two sites. The customers use private IP address space (partially overlapping). In this example, the routers in the SP network run RIPv2 for intra-domain routing, MPLS for packet forwarding, and LDP for label distribution. For the VPN service, the SP uses the approach based on MPLS and BGP defined in RFC 4364 (summarized in the next section). Customer edge routers exchange VPN routing information with the provider edge routers using RIPv2. Figure 1. Network configuration for experiments with MPLS-based VPNs. Summary of learning objectives You will set up the network shown in Figure 1 and study the following topics: Configuration of MPLS, LDP and RIPv2 in the SP network. Configuration of MPLS-based L3VPNs using: VRFs (Virtual Routing and Forwarding), MP-BGP (Multi-Protocol BGP), redistribution of VPN routes between MP-BGP and RIPv2 in VRFs, etc. Operation of the MPLS network and the VPNs. During the experiments carried out in the lab, you will see how these protocols work and cooperate to achieve the VPN service, by examining the status of the routers using Cisco IOS commands and by inspecting the exchanged packets using a protocol analyzer. 1

Overview of Layer-3 MPLS-based VPNs Virtual Routing and Forwarding (VRF) PE routers have to support multiple VPN customers and to provide logically separated routing for each VPN in order to prevent acess to a VPN from other networks. The MPLS-based VPNs defined in RFC 4364 achieve this separation using a Virtual Routing/Forwarding (VRF) instance for each VPN customer. Conceptually, VRFs are separate virtual router instances running on the same physical router (Figure 2). Each VRF has its own: VPN-specific IP routing and forwarding table. Set of interfaces associated to the forwarding table. Set of rules that control the import/export of routes to/from the VPN-specific routing table. Set of routing protocol peers that populate with routes the VPN-specific routing table. Moreover, VRFs also provide the means to deal with VPNs that use overlapping blocks of IP addresses. This occurs frequently in practice, due to the widespread use of private IP address space in private networks. For example, both private networks shown in Figure 1 use 172.16.0.0/30 and 172.16.0.4/30). Figure 2. VRF instances in PE routers provide separation of VPN routing. The VRFs use two mechanisms in order to handle overlapping addresses and route import/export policies: Route distinguisher (RD): 64-bit identifier assigned to a VPN in order to distinguish its routes in case of overlapping address spaces. Route target (RT): 64-bit identifiers used to specify route import/export policies. The RTs are exchanged as MP-BGP extended community attributes. The high order 16 bits contain the MP- BGP extended community type and the remaining 48 bits are specified as a pair of values with the syntax 16-bit : 32-bit or 32-bit : 16-bit. We use the first variant, where the 16-bit value is the AS number, as shown in the table below. We assume that the AS number of the SP network is ASN = 1. RD values are similar. VRF/VPN RD Import RT Export RT vpn_a 1:1 1:1 1:1 vpn_b 1:2 1:2 1:2 By combining a VPN RD and a VPN route prefix we obtain a unique route prefix that can be handled by the MP-BGP routing protocol. We'll refer to this addressing scheme as the VPNv4 address family. Control plane operation Figure 3 is a high level view of the end-to-end propagation of VPN routes, taking as example the VPN routes for destination VPN A, Site 1. Figure 4 provides more details about propagation of VPN routes as well as the distribution of MPLS labels using LDP. The propagation of the VPN routes is summarized below: 1. An IP route to a VPN site is first exchanged using an IGP between a CE router and the associated VRF in a PE router. We use RIPv2. CE1A advertises to VRF vpn_a in PE1 a route to Site 1 of VPN A, with prefix 172.16.1.0/24. This route is inserted in the routing table of VRF vpn_a. 2. The VRF adds the RD assigned to the VPN and then redistributes the resulting VPNv4 route into MP-BGP (Multi-Protocol BGP), together with the VPN Label and the exported RT. 2

3. MP-BGP is responsible for the exchange of VPN routes between the PE routers. PE1 advertises the VPNv4 route to PE2 using MP-iBGP and Next-Hop itself. VPN-specific information is carried in MP- BGP attributes (VPNv4 prefix, VPN label, RT). 4. VRF vpn_a at PE2 imports the route, since the local import RT matches the RT in the route. The IPv4 route is inserted in its routing table, with PE1 as next hop. The VPN Label (L A ) is also recorded. 5. VRF vpn_a at PE2 advertises the IPv4 route to router CE2A using an IGP (RIPv2). This completes the distribution of the route to 172.16.1.0/24 (Site 1 of VPN A). Figure 3. End-to-end route propagation. Observe that the VPN routes are processed only by the PE routers. The other routers in the SP network need not know anything about VPN addresses and routes. In particular, the IGP running within the SP network is not involved in VPN route propagation (it supports the VPN only by providing internal routes needed to set up LSPs between PE routers). We use RIPv2 in the SP network. Figure 4. Control plane: Route and label propagation. Data plane operation Figure 5 shows the packet forwarding for VPN A, from Site 1 to Site 2, after the final configuration of the MPLS-based VPNs. The MPLS packets carry a label stack consisting of two labels: The top label (L1, L2) corresponds to the LSP between PE1 and PE2 set up automatically by LDP. The bottom label (L A ) is the VPN label assigned to the VPN by the egress router (in this example, the label assigned to VPN A by PE2). This label allows the egress router to demultiplex the packet flow received on the LSP, indentifying the packets belonging to each VPN. Figure 5 shows that P1 pops the top label, instead of PE1. This procedure is called penultimate hop popping (PHP), i.e., an LSP label is removed by the penultimate router, rather than the last router, and was requested by PE1 during label distribution (Implicit-Null label). This avoids an unnecessary label lookup at PE1, and it is the default behavior of Cisco routers. 3

Figure 5. Packet forwarding in MPLS-based VPN. 1. Network setup The experiments are carried out using the network shown in Figure 1. The SP network consists of the edge routers PE1 and PE2 and the internal routers P1 and P2. The SP network interconnects two sites of Customer A (edge routers CE1A and CE2A) and two sites of Customer B (edge routers CE1B and CE2B). All routers run Cisco IOS and are configured with Fast Ethernet interfaces. Your task is to set up for each customer a VPN that interconnects its two sites. The instructions given in the following assume that the experiments are carried out using the network emulator GNS3. 1.1. Load the initial GNS project. You start with a GNS project that contains the network shown in Figure 1. The IP addresses are already configured, except for the VRF interfaces. Check the initial configuration of the routers. 1.2. Start the routers and check the CPU load. Start a router using GNS (right-click on the router and select Start) and then check the CPU load (on Windows, start the Task Manager and select the Performance tab). Wait until the router boots up. If the CPU load does not decrease to a low level, adjust the Idle PC parameter (right-click on the router and select Idle-PC); ask the instructor if necessary. Then start the entire network and check that the CPU load falls to a low level once all the routers boot up. 1.3. Start router consoles. Start consoles for all the routers using GNS (Console button in the toolbar). Each console should show the Cisco CLI prompt router-name# for the privileged mode, which allows you to enter any command for configuring the router or examining its status. You have to carry out a quite lengthy, incremental configuration. To make this process faster and less error prone, use the following procedure: At each step, edit using a text editor the batches of commands for all the routers you configure and then copy each batch from the text editor to the router's console window (right-click). Before proceeding to the next step, verify if the router configuration and operation are correct, save the configuration using the IOS command "copy run start" or "write" and then save the GNS project. 2. Configure interior routing in the SP network We start by setting up our SP network, and afterwards we'll create the VPNs for our clients. The IP addresses should already be configured now, so we can proceed to configure interior routing. We use for this purpose RIPv2. 2.1. Configure RIPv2 for interior routing in the SP network (routers PE1, PE2, P1, and P2). The configuration commands for PE1 are listed below (starting in global configuration mode). The configuration of the other routers is similar. 4

router rip version 2 network 10.0.0.0 Begin RIP configuration (and start RIP). Set RIP version 2. Enable RIP on interfaces connected to 10.0.0.0/8. 2.2. Test and troubleshoot internal routing in the SP network. - Examine the status of the SP routers using the commands show ip protocols and show ip route. Does the router receive information from all its neighbors in the SP network? Do you see routes to all destinations in the SP network (all links and the loopback interfaces)? - Test the connectivity between PE1 and PE2 using ping. 2.3. Save the configuration of the routers and the GNS project. 3. Configure MPLS in the SP network We're now going to configure MPLS in the SP network and examine using the protocol analyzer the packets exchanged by LDP to set up adjacencies and distribute labels. 3.1. Capture the traffic on interface f2/0 of PE1 (link between PE1 and P1). 3.2. Configure MPLS and LDP in the SP network (routers PE1, PE2, P1, and P2). Enable MPLS for all interfaces connected to the SP network (but not on the interfaces connected to the client networks). You should also have CEF (Cisco Express Forwarding) enabled for each SP router. The configuration commands for PE1 are listed below (similar for the others): ip cef mpls label protocol ldp mpls ldp router-id Loopback0 interface f2/0 mpls ip Enable CEF Set LDP for MPLS label distribution. Configure the LDP Router-ID Activate MPLS on interface f0/0 3.3. Check if MPLS and LDP are working properly. For the current (default) configuration, LDP works as follows: The router assigns labels to prefix-based FECs (destination prefixes found in the routing table), using per-platform label space. Then the router sends its own label bindings to its LDP-enabled neighbors, using independent, downstream unsolicited label distribution. - Examine the status of the LDP sessions established by the router with its neighbors: show mpls ldp neighbor Has the router successfully established LDP sessions (Open state) with all its neighbors? - Examine the router's Label Information Base (LIB): show mpls ldp bindings Note that Cisco IOS uses here the term "tag" instead of "label" (hence tsr = LSR, tib = LIB). Compare the information in the LIB with the routing table. Do you see label bindings for all (applicable) destinations? Do you see, for each destination, a local binding as well as remote bindings from all LDP neighbors? What label retention policy is being used? - Examine the router's MPLS forwarding table, also called Forwarding Information Base (FIB): show mpls forwarding-table 5

The FIB is built based on the routing table and the LIB, and is used for MPLS packet forwarding. LSPs are (implicitly) defined by matching FIB entries along the path to a destination prefix. Figure out how the FIB is built and used by comparing the information in the FIB entries with the routing table and the LIB. - Test the connectivity between PE1 and PE2 using ping (try the addresses of the loopback interfaces). 3.4. Examine the exchanged messages using the protocol analyzer. Start the Wireshark protocol analyzer (from GNS3) in order to examine the packets captured after enabling MPLS and LDP. - In Wireshark, set ldp as filter expression, in order to display the LDP messages. Examine the messages exchanged by PE1 and P1 during the LDP session setup. Compare the label bindings in the LDP messages with the information displayed by the command show mpls ldp bindings. - In Wireshark, set icmp as filter expression, in order to display the ICMP messages exchanged during the test. Do you see MPLS headers for all ICMP messages? If not, why? (Hint: The routers apply by default Penultimate Hop Popping.) 3.5. Save the configuration of the routers and the GNS project. 4. Configure RIPv2 on the customer edge (CE) routers We can now begin the configuration of the VPNs for our two customers. We start by completing the configuration of the CE routers. The interfaces should already be configured, so we can proceed to the configuration of RIPv2. 4.1. Configure and start RIPv2 on the routers CE1A, CE2A, CE1B, and CE2B. The configuration commands for CE1A are listed below (similar for the others, don't forget 172.17.0.0). router rip version 2 network 172.16.0.0 Begin RIP configuration. Set RIP version 2. Enable RIP on interfaces connected to 172.16.0.0/16. Disable route summarization. 4.2. Check if RIPv2 is working properly. Examine the current status using the commands show ip protocols and show ip route. 4.3. Save the configuration of the routers and the GNS project. 5. Create the VRFs and configure their interfaces 5.1. Create the VRFs associated to the VPNs on PE1 and PE2. A VRF is identified by a name (unique within a physical router). We call vpn_a and vpn_b the VRFs for VPN A and VPN B, respectively. The configuration commands for PE1 are listed below (similar for PE2). ip vrf vpn_a rd 1:1 route-target export 1:1 route-target import 1:1 ip vrf vpn_b rd 1:2 route-target export 1:2 Configure the VRF vpn_a Set the route distinguisher to 1:1. Set the imported and exported route target to 1:1. Configure the VRF vpn_b Set the route distinguisher to 1:2. Set the imported and exported route target to 1:2. 6

route-target import 1:2 5.2. Configure the VRF interfaces on PE1 and PE2. The configuration commands for PE1 are listed below (similar for PE2). interface FastEthernet0/0 ip vrf forwarding vpn_a ip address 172.16.0.1 255.255.255.252 no shutdown interface FastEthernet1/0 ip vrf forwarding vpn_b ip address 172.16.0.1 255.255.255.252 no shutdown Configure the interface f0/0. Associate the interface with VRF vpn_a. Assign the IP address and subnet mask to the interface. Turn on the interface. Configure the interface f1/0. Associate the interface with VRF vpn_b. Assign the IP address and subnet mask to the interface. Turn on the interface. 5.3. Examine the initial VRF configuration and status on PE1 and PE2. show ip vrf show ip vrf detail show ip vrf interfaces show ip route show ip route vrf vpn_a show ip route vrf vpn_b Status/configuration of the VRFs, summary and details. Status/configuration of the VRF interfaces. Global routing table. VRF routing table for VRF vpn_a. VRF routing table for VRF vpn_b. Is everything configured and working correctly? 5.4. Analysis of the address configuration. According to the address assignment in Figure 1, at step 5.1 you configured the same address for the interfaces f0/0 and f1/0 of router PE1. Can the network operate correctly with this configuration? Why? Furthermore, Figure 1 shows that you have to configure the address 172.16.0.5 to the interfaces f0/0 and f1/0 of router PE2. Could we have assigned the same addresses as for PE1? Why? 5.5. Save the configuration of the routers and the GNS project. 6. Configure RIPv2 on the VRFs 6.1. Configure RIPv2 to exchange routes between each CE router and the associated VRF instance. The configuration commands for the PE1 VRFs are listed below (similar on PE2). To configure RIPv2 routing for IPv4 on a VRF instance, you have to use the command address-family ipv4 vrf. router rip address-family ipv4 vrf vpn_a network 172.16.0.0 exit-address-family address-family ipv4 vrf vpn_b network 172.16.0.0 exit-address-family Begin (resume) RIPv2 configuration. Run RIP for VRF vpn_a, on interfaces connected to the (IPv4) prefix 172.16.0.0/16. Run RIP for VRF vpn_b, on interfaces connected to the (IPv4) prefix 172.16.0.0/16 (the address spaces used by the two customers overlap). 6.2. Examine the current configuration and status of the VRFs on PE1 and PE2. 7

show ip vrf show ip vrf detail show ip vrf interfaces show ip route show ip route vrf vpn_a show ip route vrf vpn_b Status/configuration of the VRFs, summary and details. Status/configuration of the VRF interfaces. Global routing table. VRF routing table for VRF vpn_a. VRF routing table for VRF vpn_b. Recall that on PE routers we have 3 separate routing tables (2 VRF tables and a global table). Is everything working correctly? Do you see now all the routes? 6.3. Examine the current status of the CE routers. Examine the routing tables of the CE routers (show ip route). Test the connectivity between CE routers and PE routers using ping. 6.4. Save the configuration of the routers (PE1, PE2) and the GNS project. 7. Configure MP-BGP on PE routers The VPN routes will be propagated between PE routers using MP-BGP. We'll configure this in several steps. 7.1. Configure and start BGP on PE1 and PE2. Start BGP on PE1 and PE2 and establish a BGP connection between them. The AS number (ASN) of the SP network is ASN = 1. The configuration commands for PE1 (10.100.255.1) are listed below (symmetric configuration for PE2). router bgp 1 network 10.100.255.1 mask 255.255.255.255 neighbor 10.100.255.4 remote-as 1 neighbor 10.100.255.4 update-source Loopback0 no synchronization Begin BGP configuration for the AS with ASN = 1. Advertise BGP routes to the prefix 10.100.255.1/32. Establish a BGP connection to 10.100.255.4 (PE1) in AS 1 (ibgp), using as source address the address of the interface Loopback0. 7.2. Configure MP-BGP for VPNs on PE1 and PE2. The configuration commands for PE1 are listed below (symmetric configuration for PE2). router bgp 1 address-family vpnv4 neighbor 10.100.255.4 activate neighbor 10.100.255.4 send-community extended neighbor 10.100.255.4 next-hop-self Begin (resume) BGP configuration for AS 1. Begin configuration for the address family vpnv4. For the BGP connection to 10.100.255.4: advertise vpnv4 routes; send Extended Community attributes (for RT); set the Next-Hop attribute of the routes to PE1's own address. 7.3. Examine the current BGP configuration and status. sh ip bgp summary sh ip bgp all sh ip route sh ip bgp neighbors 8

Is there a BGP session between PE1 and PE2? Do you see all the routes you expected in the routing tables? Why is it necessary to ask MP-BGP to set the Next-Hop attribute of the advertised VPN routes to the sender's own address (next-hop-self)? How will this affect VPN traffic forwarding in the SP network? 7.4. Save the configuration of the routers (PE1, PE2) and the GNS project. 8. Configure route redistribution between RIPv2 and MP-BGP We need to redistribute the VPN routes between RIPv2 and BGP in the VRFs, in order to enable the propagation of the VPN routes between the CE routers, via the PE routers. 8.1. Configure RIP to redistribute BGP routes, on PE1 and PE2. The configuration commands for PE1 are listed below (similar for PE2): router rip address-family ipv4 vrf vpn_a redistribute bgp 1 metric transparent exit-address-family address-family ipv4 vrf vpn_b redistribute bgp 1 metric transparent Begin (resume) RIPv2 configuration. Begin configuration for address family ipv4 for VRF vpn_a. Redistribute BGP routes (for AS 1) into RIP, preserving the RIP metric. Similar for VRF vpn_b. 8.2. Configure BGP to redistribute RIP routes, for the VRFs created in PE1 and PE2. The configuration commands for PE1 are listed below (same commands for PE2): router bgp 1 address-family ipv4 vrf vpn_a redistribute rip no synchronization exit-address-family address-family ipv4 vrf vpn_b redistribute rip no synchronization Begin (resume) BGP configuration for AS 1. Begin configuration for address family ipv4 for VRF vpn_a. Redistribute RIP routes from VRF vpn_a into BGP. Similar for VRF vpn_b. 8.3. Examine the current BGP configuration and status. sh ip bgp summary sh ip bgp all sh ip route sh ip route vrf vpn_a sh ip route vrf vpn_b You should find now all the VPN routes in the BGP routing tables of PE1 and PE2. Do you also see all the VPN routes in the PE/VRF and CE routing tables? 8.4. Save the configuration of the routers (PE1, PE2) and the GNS project. 9

9. VPN operation (data and control planes) At this point, we completed the VPN configuration. The VPN routes should be present in the routing tables of the VRFs and of the CE routers. 9.1. Test the connectivity between the two sites of the same VPN. Use ping, e.g., from CE1A to CE2A: ping 172.16.2.1 source 172.16.1.1 repeat 10 9.2. Examine the data plane operation using the protocol analyzer. Capture the traffic at the interface f1/0 of P1 (link between P1 and P2) using GNS3. Generate data traffic between the VPN sites using ping. Examine the exchanged packets using Wireshark (filter icmp). Compare the MPLS headers with the contents of the Label Information Base (show mpls ldp bindings) and Forwarding Information Base (show mpls forwarding-table) of P1 and P2. 9.3. Examine the control plane operation using the protocol analyzer. Capture the traffic at the interface f1/0 of P1 (link between P1 and P2) using GNS3. - Turn off the interface f0/0 of CE1A (shutdown). Examine the exchanged BGP packets using Wireshark (filter bgp). What is the effect of turning off this interface on the VPNs? How does BGP learn about this event? How does BGP react to the event? - Turn on the interface f0/0 of CE1A (no shutdown). Examine the exchanged BGP packets using Wireshark (filter bgp). Same questions as above. 10. Optional 10.1. Is it possible to transfer IP packets between a site of VPN A and a site of VPN B with the current configuration? Why? 10.2. Modify the configuration of the routers PE1 and PE2 such that: (a) Site 1 of VPN A can communicate with the other site of VPN A as well as with Site 1 of VPN B. (b) Site 2 of VPN A can only communicate with Site 1 of VPN A. (c) Site 2 of VPN B can only communicate with Site 1 of VPN B. 10