ETTI.

Lab: MPLS TE FRR VPN (V1)

Octavian Catrina, 2012

MPLS VPN over TE Tunnels and Fast Rerouting

Overall objective The main MPLS design objectives were to provide enhanced support for Traffic Engineering (TE), Virtual Private Networks (VPN), and resilient networks. In this lab you will study some of the core MPLS protocols and mechanisms used for these purposes, including: Configuration and operation of dynamic and explicit MPLS Traffic Engineering (TE) tunnels. Resilience in case of link/node failure with/without enabling Fast Re-Routing (FRR) protection. MPLS VPN configuration and operation over MPLS TE tunnels.

Prerequisites You should be familiar with the basic concepts and operation of MPLS, RSVP-TE (Resource Reservation Protocol with TE extensions), OSPF-TE (OSPF with TE extensions), inter-domain routing using BGP, as well as with the principles of Layer-3 VPNs based on MPLS and BGP. Case study We consider an MPLS network with the topology shown in Figure 1. The service provider SP has an MPLS TE network and sets up VPNs for the customers A and B.

Figure 1. Network configuration. Summary of learning objectives You will configure on Cisco routers and experiment with the following MPLS features: Dynamic and explicit MPLS TE tunnels, including configuration and operation of MPLS TE, OSPFTE (OSPF with TE extensions), RSVP-TE (Resource Reservation Protocol with TE extensions). Automatic tunnel recovery in case of link and node failure by re-routing. Tunnel protection using Fast Re-Routing (FRR): link protection and node protection.

VPNs over MPLS TE tunnels, including the configuration and operation of VRF, OSPF, and BGP. You will learn how these mechanisms and protocols work by examining the state of the routers using Cisco IOS commands and studying the exchanged packets using a protocol analyzer.

ETTI. Lab: MPLS TE FRR VPN (V1)

Octavian Catrina, 2012

Outline of the MPLS TE configuration and operation

MPLS Traffic Engineering (TE) and supporting protocols MPLS TE allows to set up MPLS LSPs according to certain performance and policy requirements and allocate the network resources (usually bandwidth) necessary in order to satisfy the performance requirements. In the following, we'll call these LSPs MPLS TE tunnels. The overall goal is to map traffic to network resources such that to optimize traffic performance and network resource utilization. Another impotant objective is to ensure fast recovery in case of failures. MPLS TE uses RSVP-TE as signaling protocol for tunnel setup. RSVP-TE distributes MPLS labels and at the same time allocates network resources in each node along the path. Since the tunnel's path has to satisfy certain specific constraints, MPLS TE cannot rely on the hop-by-hop, destination-based IP routing paradigm and traditional routing protocols. MPLS TE uses explicit (sourcerouted) LSPs and routing protocols and algorithms able to find paths subject to a set of constraints and resource efficiency objectives (constraint-based routing). A standard solution is to use OSPF or IS-IS link state protocols with TE extensions, that distribute a set of link attributes necessary for TE (e.g., available bandwidth), besides the usual link metric. The path can then be computed using the resulting TE database and, e.g., CSPF (Constrained SPF) routing algorithm, instead of the usual SPF algorithm. MPLS TE Tunnels Figure 2 shows the MPLS TE tunnels that will be set up between PE1 and PE2 and will carry the VPN traffic, according to the case study depicted in Figure 1 (for bi-directional connectivity we need 2 tunnels, one for each direction).

Figure 2. MPLS TE Tunnels between routers PE1 and PE2.

Figure 3. Setup of a tunnel from PE1 to PE2 using RSVP-TE (Tunnel0). 2

ETTI. Lab: MPLS TE FRR VPN (V1)

Octavian Catrina, 2012

Figure 3 shows the RSVP messages exchanged in order to setup a tunnel from PE1 to PE2. RSVP-TE uses downstream on-demand label distribution initiated by the tunnel's headend router (PE1). PE1 determines a suitable path and then directs RSVP to set up the tunnel using explicit routing (list of intermediate nodes). The PATH message is forwarded along the path specified in the EXPLICIT_ROUTE object. Each hop performs admission control to determine if there is sufficient bandwidth on the downstream link to match the traffic specification in the SENDER_TSPEC object. The RESV message is forwarded upstream along the path marked by the PATH message and communicates upstream the label assigned by each node (LABEL object). Each node reserves on the downstream link the bandwidth specified in the RSPEC object. The RSVP session state is soft state, meaning that it must be refreshed by periodic PATH and RESV messages transferred along the path between the tunnel headend and tailend (otherwise it is deleted). Fast Rerouting (FRR) As you'll see during the lab, routers are able to automatically repair a tunnel in case of link or node failure by re-routing the tunnel on another path (if such path exist). This repair process relies on the routing protocol to find a feasible path and on RSVP-TE to carry out the label distribution and reservation for the new path. The delay until a failure is detected depends on many factors and can vary from milliseconds to tens of seconds, and hecne become too large for many important applications (e.g., interactive voice). FRR is a mechanism for protecting MPLS TE LSPs from link and node failures by locally repairing them at the point of failure. FRR locally repairs the protected LSPs by rerouting them over (already established) backup tunnels that bypass a failed link or node. The goal is to allow data to continue to flow on LSPs in case of failure while the LSPs headend routers attempt to establish new end -to-end LSPs to replace them. There are two standard methods, link protection and node protection, shown in Figure 4. The overall repair delay still depends on the delay until the failure is detected, but in certain configuration it can be reduced to tens of milliseconds. In this lab you will experiment with automatic tunnel repair by re-routing in case of link or node failure and you will learn how to configure FRR link and node protection.

Figure 4. Fast Reroute: Link prtection and node protection. VPN over TE tunnels MPLS-based VPNs can be deployed over MPLS TE networks using the same general methods as for nonTE networks. An important advantage of VPNs over MPLS TE is that it is possible to set up paths and reserve bandwidth such that to satisfy the QoS requirements of the clients. Figure 5 shows the control plane operation for a VPN with two sites, using as example the transfer of VPN routing information from site 1 to site 2. In this lab we use OSPF for the exchange of routing information between CE and PE routers. Figure 6 shows the corresponding data plane operation, i.e., data transfer from site 1 to site 2 over the TE tunnel between PE1 and PE2.

ETTI. Lab: MPLS TE FRR VPN (V1)

Octavian Catrina, 2012

Figure 5. Control plane operation for VPN over (established) TE tunnel.

Figure 6. Data forwarding for VPN over TE tunnel.

1. Network setup
We use the network configuration shown in Figure 1. All interfaces are Fast Ethernet. The instructions given in the following assume that the experiments are carried out using the network emulator GNS3. 1.1. You start with a GNS project that contains the network topology shown in Figure 1, with IP addresses already configured for all routers. Check the initial configuration of the routers. 1.2. Start a router and check the CPU load. Wait until the router boots up. If the CPU load does not decrease to a low level, adjust the Idle PC parameter (ask the instructor if necessary). Then start the entire network. Remark: For each step, verify if the current router configuration and operation are correct, then save the configuration and the GNS project, before proceeding to the next step. To speed up the configuration process, edit at each step the batches of commands for all the routers you configure using a text editor, then copy each batch from the text editor to the router's console window (right-click).

2. Configure interior routing in the SP network

2.1. Configure OSPF for a single area on all SP routers. The configuration commands for PE1 are listed below (similar for the other routers).

router ospf 100 network 10.0.0.0 0.255.255.255 area 0

Configure OSPF process 100. Enable OSPF routing for 10.0.0.0/8 in area 0.

2.2. Verify the configuration (sh run) and save it (copy run start, then save the GNS project). 2.3. Check if OSPF is working properly. Examine the current status using the commands sh ip protocols and sh ip route.

ETTI. Lab: MPLS TE FRR VPN (V1)

Octavian Catrina, 2012

Is OSPF running? Did all the routers exchange updates? Do you see routes to all destinations? Do you see multiple routes to some destinations? Why?

3. Configure MPLS TE in the SP network

3.1. Start capturing the traffic on the interfaces f1/0 and f1/1 of router PE1. 3.2. Enable MPLS TE and RSVP signaling on all SP routers (PE1, PE2, P1, P2, P3). The configuration commands for PE1 are listed below (similar for the other routers).

mpls traffic-eng tunnels interface f1/0 mpls traffic-eng tunnels ip rsvp bandwidth 50000 1000 interface f1/1 mpls traffic-eng tunnels ip rsvp bandwidth 50000 1000

Enable MPLS TE on the device. Enable MPLS TE on the interface f1/0. Enable RSVP on the interface and specify the maximum bandwidth available for reservation and the maximum bandwidth reservation per tunnel. Enable MPLS TE on the interface f1/1.

3.3. Configure OSPF for TE on all SP routers. The configuration commands for PE1 are listed below (similar for the other routers).

router ospf 100 mpls traffic-eng area 0 mpls traffic-eng router-id loopback 0

Configure OSPF process 100. Enable OSPF TE for area 0. Set the OSPF TE router ID as the IP address of the interface loopback 0.

3.4. Verify the configuration and save it. 3.5. Examine the MPLS TE status using the command: sh mpls interfaces 3.6. Examine the RSVP status using the commands: sh ip rsvp interfaces sh ip rsvp 3.7. Analyze the captured traffic using Wireshark. Examine the OSPF packets exchanged after enabling OSPF TE. You should see OSPF Update messages containing TE LSAs. Examine the contents of these LSAs. What is the purpose of these OSPF TE Update messages?

4. Configure a dynamic MPLS TE tunnel from PE1 to PE2

In this step we set up a first MPLS TE tunnel from PE1 to PE2, with 1 Mbps bandwidth. We use the dynamic path option, meaning that the tunnel's path is automatically determined by the headend router using CSPF (Constrained SPF) path computation and its local TE database (TED) constructed by OSPF-TE. We do not configure a TE metric on the links, so the path computation will use the default OSPF metric, which is 1 for Fast Ethernet links. Thus, our dynamic tunnel will use the path PE1-P1-PE2 (Why?).

ETTI. Lab: MPLS TE FRR VPN (V1)

Octavian Catrina, 2012

Continue capturing the traffic on the interfaces f1/0 and f1/1 of router PE1. 4.1. Configure on router PE1 a dynamic MPLS TE tunnel to router PE2 using the commands listed below.

interface tunnel0 ip unnumbered loopback0 tunnel destination 10.10.1.3 tunnel tunnel tunnel tunnel mode mpls mpls mpls mpls traffic-eng traffic-eng priority 1 1 traffic-eng bandwidth 1000 traffic-eng path-option 1 dynamic

tunnel mpls traffic-eng autoroute announce 4.2. Verify the configuration and save it.

Configure tunnel 0 interface (tunnel headend). Set the IP address of the tunnel interface (the same as loopback 0 interface address). Set the IP address of the tunnel's tailend (loopback 0 interface of PE2). Set tunnel encapsulation mode as MPLS TE. Set the tunnel's setup and holding priorities to 1. Set the tunnel's bandwidth to 1000 Kbps. Configure first (and only) path option for the tunnel as dynamic (determined by the routing protocol). Let OSPF use the tunnel in its path calculations.

4.3. Examine the current status of the tunnel (on PE1, PE2, P1) using the commands: show mpls traffic-eng tunnels summary show mpls traffic-eng tunnel0 Is the tunnel configured correctly? Is it working correctly? What is the tunnel's path? Try also the following commands: show mpls traffic-eng tunnels brief show mpls traffic-eng tunnels show mpls traffic-eng tunnels destination 10.10.1.3 4.4. Examine the current status of RSVP (on PE1, PE2, P1) using the commands: sh ip rsvp reservation sh ip rsvp installed Is the bandwidth required by the tunnel reserved on all the links of the path? 4.5. Examine the changes in the routing table of PE1 using the commands: sh ip route sh ip route 10.10.1.3 Is the tunnel used for routing IP packets to PE2? 4.6. Analyze the captured traffic using Wireshark. Examine the RSVP-TE packets exchanged after setting up the tunnel. You should see the initial PATH/RSVP messages that set up the tunnel, followed by periodic PATH/RSVP exchanges. Examine the contents of these RSVP-TE messages. Why is RSVP using explicit routing in the PATH messages? What is the purpose of the periodic RSVP/PATH messages? 4.7. Test connectivity between PE1 and PE2. Execute on PE1 the command: ping 10.1.1.3 source 10.10.1.1 Examine the exchanged ICMP messages using Wireshark. Are the ICMP requests delivered via the tunnel? What happens to the ICMP replies?

ETTI. Lab: MPLS TE FRR VPN (V1)

Octavian Catrina, 2012

5. Test tunnel recovery by re-routing in case of failure

We now make several experiments to see how MPLS-TE behaves in case a link or a node on the tunnel's path fails (without enabling path protection using Fast Re-Route mechanisms). Continue capturing the traffic on the interfaces f1/0 and f1/1 of router PE1. 5.1. Test recovery by automatic re-routing in case of link failure. Execute on PE1 the command: ping 10.1.1.3 source 10.10.1.1 repeat 100 Then shut down the interface f1/1 of P1 (link between P1 and PE2). You should see a temporary loss of connectivity followed by recovery after a short time interval (<10 sec). 5.2. Examine how the tunnel has changed (on PE1, P1, P2, P3, PE2) using the commands: show mpls traffic-eng tunnels brief show mpls traffic-eng tunnel0 show ip rsvp reservation What is the current path of the tunnel? Is bandwidth reserved on the new path? What happened to the previous path? 5.3. Examine how the routing table has changed (on PE1) using the commands: sh ip route 10.10.1.3 sh ip route What has changed? 5.4. Analyze using Wireshark the traffic captured on the interfaces f1/0 and f1/1 of router PE1. Examine the OSPF and RSVP-TE messages exchanged during the re-routing of the tunnel. Figure out how was the re-routing achieved in this scenario: Which router detected the failure? How was the information about the link failure distributed within the network? Which router carried out the re-routing of the tunnel? How was the re-routing achieved? What happened to the bandwidth reservations which are no longer used? 5.5. Activate the interface you have shut down (no shut). Examine again the status of the tunnel and the routing table using the commands listed above. Is there any change? 5.6. Re-optimization of the tunnel paths is scheduled by default every 3600 seconds. Therefore, although the interface f1/1 of P1 is again operational, the network still uses for our tunnel the re-routed non-optimal path. Request immediate re-optimization by running the command: mpls traffic-eng reoptimize Examine again the status of the tunnel and the routing table using the commands listed above. Is the tunnel now using the optimal path? 5.7. Test recovery by automatic re-routing in case of node failure. Execute on PE1 the command: ping 10.1.1.3 source 10.10.1.1 repeat 100 Then suspend router P1 using GNS. You should see a temporary loss of connectivity followed by recovery after a longer time interval. 5.8. Examine the status of the tunnel and the routing table using the commands listed above. You should see that the tunnel was re-routing again on the alternate non-optimal path. 7

ETTI. Lab: MPLS TE FRR VPN (V1)

Octavian Catrina, 2012

Figure out how was the re-routing achieved in this scenario: Which router(s) detected the failure? How did they detect it? How was the information about the failure distributed within the network? Which router carried out the tunnel re-routing? How was the re-routing achieved? 5.9. Re-start the router P1 using GNS, re-optimize the paths, and verify the result (tunnel, routing table).

6. Configure FRR node/link protection

We configure in the following FRR node protection for the node P1 and enable it for tunnel 0. 6.1. Configure on router PE1 a next-next-hop (NNH) explicit backup tunnel, routing around P1 towards PE1, using the commands listed below.

interface tunnel10 ip unnumbered loopback0 tunnel destination 10.10.1.3 tunnel mode mpls traffic-eng tunnel mpls traffic-eng priority 2 2 tunnel mpls traffic-eng path-option 1 explicit name LSP10

Configure tunnel 10 interface (tunnel headend). Set the IP address of the tunnel interface (the same as loopback 0 interface address). Set the IP address of the tunnel's tailend (loopback 0 interface of PE2). Set tunnel encapsulation mode as MPLS TE. Set the tunnel's setup and holding priorities to 2. Configure the path option for tunnel10 as explicit path LSP10 (to be defined later). .

6.2. Configure on PE1 the explicit path LSP10, routing around P1, using the commands listed below.

ip explicit-path LSP10 exclude-address 10.10.1.2

Configure LSP10 explicit path Explicit path that avoids next-hop P1 (to be determined by the router).

Equivalent configuration of the explicit path LSP10 (for our network topology):

ip explicit-path LSP10 next-address 10.10.0.10 next-address 10.10.0.26 next-address 10.10.0.21

Configure the explicit path LSP10. Configure next-hops on the path (P2, P3, PE2).

6.3. Configure on PE1 node protection for tunnel 0.

interface tunnel0 tunnel mpls traffic-eng fast-reroute node-protect

Enter configuration mode for interface tunnel0. Enable FRR node protection for tunnel0.

6.4. Configure on PE1 the FRR-protected interface f1/0, assigning tunnel10 as backup tunnel.

interface f1/0 mpls traffic-eng backup-path tunnel10

Enter configuration mode for interface tunnel0. Assign tunnel10 as backup path for downstream node (or link).

ETTI. Lab: MPLS TE FRR VPN (V1)

Octavian Catrina, 2012

6.5. Verify the configuration and save it. 6.6. Examine the status of the FRR node-protection using the following commands: show mpls traffic-eng tunnels brief show mpls traffic-eng tunnels backup show mpls traffic-eng fast-reroute database show ip rsvp sender detail Is the backup tunnel configured correctly? Is it (reported as) working correctly? Is FRR enabled for the protected tunnel? 6.7. Optional: Configure FRR link protection for the link between PE1 and P1 and enable it for tunnel 0. The configuration commands are similar. The only differences are: remove node-protect at step 6.3; specify the address of P1's interface f1/0 (instead of P1's router id) at step 6.4.

7. Configure a dynamic MPLS TE tunnel from PE2 to PE1

MPLS TE tunnels are unidirectional. In order to set up the VPN, we need bi-directional connectivity between PE1 and PE2, therefore we need another tunnel from PE2 to PE1. 7.1. Configure on PE2 a dynamic MPLS TE tunnel to PE1 as described in Section 4. 7.2. Verify the configuration and save it. 7.3. Examine the status of the MPLS tunnels as explained in Section 4.

8. Configure a VPN over TE tunnels

Continue capturing the traffic on the interfaces f1/0 and f1/1 of router PE1. 8.1. Configure on PE1 and on PE2 the VRF to be used for the VPN. The configuration commands for PE1 are listed below (similar for PE2).

ip vrf VPN1 rd 1:100 route-target export 1:10 route-target import 1:10

Configure the VRF VPN1 Set the route distinguisher to 1:1. Set the imported/exported route target to 1:10.

8.2. Configure on PE1 and on PE2 the interface associated to the VRF (interface to CE router). The configuration commands for PE1 are listed below (similar for PE2).

interface f2/0 ip vrf forwarding VPN1 ip address 10.20.0.1 255.255.255.252

Configure the interface f2/0 Associate the interface with VRF VPN1. Assign the IP address to the interface.

8.3. Configure OSPF on the VRF defined above, on PE1 and on PE2. Redistribute BGP routes to OSPF. The configuration commands for PE1 are listed below (similar for PE2).

ETTI. Lab: MPLS TE FRR VPN (V1) router ospf 1 vrf VPN1 redistribute bgp 100 subnets network 10.20.0.0 0.0.3.255 area 0

Octavian Catrina, 2012 Enable OSPF routing for the VRF VPN1, enter router configuration mode. Enable redistribution of routing information from BGP to OSPF on VRF VPN1. Configure the network prefix and area for which OSPF works.

8.4. Configure BGP on PE1 and PE2 for internal MP-BGP (exchange of VPN routes) with redistribution of routes from OSPF on VRF to BGP. The configuration commands for PE1 are listed below (similar for PE2).

router bgp 100 neighbor 10.10.1.3 remote-as 100 neighbor 10.10.1.3 update-source loopback0 no auto-summary address-family vpnv4 neighbor 10.10.1.3 activate neighbor 10.10.1.3 send-community extended exit-address-family address-family ipv4 vrf VPN1 redistribute ospf 1 vrf VPN1 exit-address-family

Configure BGP process in AS 100. Add BGP neighbor 10.10.1.3 in AS 100. Use loopback0 IP address for BGP session with neighbor. Enter vpnv4 address family configuration mode. Activate exchange of information with neighbor. Send extended community attributes to neighbor. Enter ipv4 configuration mode for VRF VPN1. Enable redistribution of routing information from the OSPF on VRF VPN1 to BGP.

8.5. Configure OSPF on CE1 and CE2 routers. The configuration commands for CE1 are listed below (similar for CE2).

router ospf 100 network 10.0.0.0 0.255.255.255 area 0

Enable OSPF routing (process 100), enter router configuration mode. Configure the network prefix and area for which OSPF works.

8.6. Verify the configuration and save it. 8.7. Examine the status of VPN routing on PE1 and PE2 using the following commands: sh ip vrf sh ip bgp summary sh ip bgp all sh ip route vrf VPN1 Are the VRFs configured correctly? Are the VPN routes redistributed between OSPF and BGP? Did BGP neighbors PE1 and PE2 exchange the VPN routes? Are the VPN routes present in the VRF routing tables? 8.8. Examine the VPN routing on CE1 and CE2 using the command: sh ip protocols sh ip route Are the OSPF neighbors exchanging information? Are the VPN routes present in the VRF routing tables? 8.9. Test connectivity between CE1 and CE2 using ping. 10

ETTI. Lab: MPLS TE FRR VPN (V1)

Octavian Catrina, 2012

8.10. Analyze using Wireshark the traffic captured on the interface f1/0 of router PE1. Examine the ICMP messages exchanged during the ping test. Are the ICMP requests and replies transferred on the TE tunnel? Explain the MPLS headers of the ICMP requests and replies.

9. Optional: Configure a second VPN with a dedicated tunnel

This step will be discussed in class.

11