ETTI. Lab: IP multicast (V1.

1)

Octavian Catrina, 2013

Lab: IP Multicast
Overall objective The purpose of this lab is to study multicast communications in IP networks: IP multicast, IGMP (Internet Group Management Protocol), and the multicast routing protocols PIM-DM and PIM-SM (Protocol Independent Multicast - Dense Mode, Sparse Mode). Prerequisites You should be familiar with the basic concepts and operation of IP multicast, IGMP, PIM-DM, PIM-SM. These topics are presented in the course material or/and lab slides. Review them before the lab. Additionally, you'll need basic knowledge of IP networks and IP configuration of Cisco routers. Case study The experiments will be carried out using the network emulator GNS3. Figure 1 shows the IP network used for this purpose. It consists of 4 Cisco routers, RA-RD, and 4 hosts, HA-HD, interconnected by Fast Ethernet links. All the devices support the IP multicast protocols studied in the lab. The 4 hosts will be used as multicast senders and receivers, in different scenarios, as instructed for each experiment (actually, for convenience, the hosts are also routers).

Figure 1. Network configuration for IP multicast experiments. Summary of learning objectives You will set up the network shown in Figure 1 and study the following topics: Configuration of IP, RIP, IGMP, PIM-DM, and PIM-SM on Cisco routers. Operation of the protocols IGMP, PIM-DM, and PIM-SM in various scenarios, allowing to examine their specific mechanisms and approaches to multicast routing. You will learn how the protocols work by examining the status of the routers using Cisco IOS commands and by studying the exchanged packets using a protocol analyzer. Starting and stopping the multicast receivers and senders All experiments will use the multicast address 239.2.3.9. You can use the following commands to make our "hosts" join or leave the multicast group (in real life, an application running on the host calls API functions for this purpose, but the effect in the network is the same): - The "host" joins the multicast group - start multicast receiver: conf term int f0/0 ip igmp join-group 239.2.3.9

ETTI. Lab: IP multicast (V1.1)

Octavian Catrina, 2013

- The "host" leaves the multicast group - stop multicast receiver: conf term int f0/0 no ip igmp join-group 239.2.3.9 - You can start a multicast sender at a "host" using the command: ping 239.2.3.9 repeat 100 This transmission will last only 200 seconds (execute again the command when necessary or use a larger repeat value). To stop the multicast sender you can use the escape sequence ctrl-shift-6.

1. Network setup
You'll use the network shown in Figure 1 for all the experiments carried out in this lab. 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 topology shown in Figure 1. The initial configuration of the devices contains only the host name of each device (and the default settings). 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 routers boot up. 1.3. Start router consoles. Start consoles for all the routers and hosts using GNS (use the Console button in the toolbar or right-click on the device and select Console). Each console should show the Cisco CLI prompt router-name# for privileged mode that allows you to enter any command for configuring the router or examining its status. 1.4. Configure IP and RIP on the routers as shown in Figure 1. The configuration commands for the router RC are listed below (starting from router-name# prompt). The configuration of the other routers is similar. configure terminal hostname RC int f0/0 ip address 192.168.6.1 255.255.255.0 no shutdown int f1/0 ip address 192.168.4.2 255.255.255.0 no shutdown int f2/0 ip address 192.168.7.1 255.255.255.0 no shutdown router rip version 2 no auto-summary network 192.168.4.0 network 192.168.6.0 network 192.168.7.0 Enter configuration mode (input from console). Set the hostname. Enter interface configuration mode for f0/0. Configure the IP address and mask for f0/0. Turn on the interface f0/0. Similar for the other interfaces.

Enter RIP configuration mode, start RIP process. Set RIP version 2. Disable route summarization. Activate RIP routing for 192.168.4.0/24. Similar for the other connected networks.

ETTI. Lab: IP multicast (V1.1)

Octavian Catrina, 2013

1.5. Configure IP on the "hosts" as shown in Figure 1. The configuration commands for HC are listed below (starting from router-name# prompt). The configuration of the other "hosts" is similar. configure terminal hostname HC int f0/0 ip address 192.168.6.2 255.255.255.0 no shutdown ip route 0.0.0.0 0.0.0.0 192.168.6.1 Enter configuration mode (input from console). Set the hostname. Enter interface configuration mode for f0/0. Configure the IP address and mask for f0/0. Turn on the interface f0/0. Set a static route to the default gateway.

1.6. Verify the configuration of each device (show run), save it (copy run start or just write), and then save the GNS project. 1.7. Examine the status of the routers and the hosts and check if everything is working properly, using the following commands: show interface show ip protocols show ip route Show the status of all interfaces. Show the active routing protocols and their status. Show the IP (unicast) routing table.

Check that: All interfaces used in the network are up (e.g., FastEthernet0/0 is up, line protocol is up). RIP runs on every router, routing for all the (directly) connected subnetworks, and has received routing information from each neighbor router. The routing tables of the routers contain routes to all the 8 subnetworks. The routing tables of the hosts contain routes to the local subnetwork and its gateway. 1.8. Test end-to-end connectivity using the command ping.

2. Multicast configuration for PIM-DM

2.1. Activate multicast routing using PIM-DM on all the routers. The configuration commands for RB are listed below (starting in global configuration mode). The configuration of the other routers is similar. ip multicast-routing interface f0/0 ip pim dense-mode interface f1/0 ip pim dense-mode interface f2/0 ip pim dense-mode interface f3/0 ip pim dense-mode Activate multicast routing globally. Enable multicast routing with PIM-DM for each active interface.

Exit configuration mode. Check the configuration and then save it. Note that enabling PIM on an interface also enables IGMP on that interface. 2.2. Examine the status of IGMP by typing the commands listed below on any router: show ip igmp interface show ip igmp groups - Is IGMP enabled on all the interfaces? 3

ETTI. Lab: IP multicast (V1.1)

Octavian Catrina, 2013

- What is the current IGMP version? (It can be changed using the command: ip igmp version.) - What is an IGMP querying router? Why is it necessary and how is it selected? - Which are the multicast groups that the router has joined? (224.0.1.40 is used by the Cisco Discovery Protocol.) 2.3. Examine the current status of PIM-DM by typing the following commands on any router: show ip pim interface show ip pim neighbor show ip mroute - Is PIM-DM enabled on all the interfaces? (Further details: show ip pim interface detail.) - Has the router discovered all its PIM-DM neighbors? What is the PIM Hello interval? - What routing information is currently in the multicast routing table? (Are there actual PIM-DM routes?)

3. IGMP operation
Routers use IGMP to learn the multicast addresses for which there are multicast receivers in the networks attached to their interfaces. Conversely, multicast receivers must report their membership in multicast groups to their local routers using IGMP. In the next experiments, you'll study IGMP operation. Initially, all multicast senders and receivers are stopped. 3.1. Start capturing the traffic at the interface of host HA. 3.2. Start the multicast receiver at host HA. - Examine the IGMP status at router RA using the command: show ip igmp groups. - Examine the multicast routing table of RA using the command: show ip mroute. - Explain the new entries in the group membership list and the multicast routing table. 3.3. Stop the multicast receiver at host HA. - Examine the IGMP status at router RA using the command: show ip igmp groups. - Examine the multicast routing table of RA using the command: show ip mroute. Repeat several times (routes expire after several minutes). - Explain the changes in the group membership list and the multicast routing table. 3.4. Inspect using Wireshark the traffic captured during this test at HA's interface. - Set "igmp" as view filter (select IGMP packets). - Examine the IGMP packets and explain the interactions.

4. PIM-DM operation
Recall the basic principles of PIM-DM: - PIM-DM provides source-based multicast trees. - Tree setup and maintenance is data-driven, in the sense that the network creates a tree when multicast packets start flowing from a source and maintains the tree as long as the transmission continues. - Multicast routing information is soft state, meaning that it is periodically refreshed (and updated) as long as it is relevant, and then it is automatically removed. - PIM-DM finds a shortest-path tree rooted at the source using the existing unicast routing tables and the reverse-path forwarding (RPF) test. - The multicast tree is set up using the broadcast and prune method, meaning that the multicast traffic is initially broadcast based on the RPF test, then the routers remove (prune) the branches that are not necessary. The tree is updated by periodically repeating this procedure. 4

ETTI. Lab: IP multicast (V1.1)

Octavian Catrina, 2013

- The graft mechanism faster reconnection of pruned branches, without waiting for the next broadcast. The purpose of the next experiments is to study these core PIM-DM features. All multicast senders and receivers are initially stopped. 4.1. Experiment 1: Multicast receivers stopped. A multicast sender starts transmission. - Display the initial multicast routing table of each router (show ip mroute). - Capture the traffic at the interface 192.168.2.2 of the router RB. - Start the multicast sender at host HC. - Display the IGMP status (show ip igmp groups) of RC and the multicast routing table of each router. Analyze the changes. Do you see any multicast tree? Explain what happened. - Inspect using Wireshark the PIM-DM packets and the multicast packets (ICMP Echo Request) exchanged during this test and explain them (filter: "pim or icmp"). 4.2. Experiment 2: Multicast sender stopped. Multicast receivers join the multicast group. - Stop the multicast sender, if still active. - Start the multicast receiver at host HD. - Display the IGMP status of RD and the multicast routing table of each router. Analyze the changes. Do you see any multicast tree? Explain what happened. - Start the multicast receiver at host HB. - Display the IGMP status of RB and the multicast routing table of each router. Analyze the changes. Do you see any multicast tree? Explain what happened. 4.3. Experiment 3: Multicast receivers started. A multicast sender starts transmission. - The multicast group 239.2.3.9 has now 2 receivers, HB and HD. - Start the multicast sender at host HC. - Display the multicast routing table of each router and analyze the changes. - Draw the multicast tree according to the routing tables and explain what happened. 4.4. Experiment 4: A multicast receiver joins the multicast group during transmission. - Capture the traffic at the interface 192.168.2.2 of the router RB. - The multicast group 239.2.3.9 has 2 receivers, HB and HD. - Start the multicast sender at host HC. - Start the multicast receiver at host HA. - Display the multicast routing table of each router and analyze the changes. Draw the multicast tree according to the routing tables. - Inspect using Wireshark the PIM-DM packets and the multicast packets (ICMP Echo Request) exchanged during this test and explain them (filter: "pim or icmp"). 4.5. Experiment 5: Second multicast sender starts transmission. - The multicast group 239.2.3.9 has now 3 receivers, HA, HB and HD. - Start the multicast sender at host HC. - Start the multicast sender at host HB. - Examine the multicast routing table of each router and identify the changes. You should find two multicast trees. Draw the multicast trees according to the routing tables and explain what happened. 4.6. Experiment 6: Multicast receivers leave the multicast group during transmission. - Capture the traffic at the interface 192.168.2.2 of the router RB. - The multicast group 239.2.3.9 has 3 receivers, HA, HB and HD. - Start the multicast sender at host HC. - Stop the multicast receiver at host HA. 5

ETTI. Lab: IP multicast (V1.1)

Octavian Catrina, 2013

- Examine the multicast routing table of each router and identify the changes. Draw the multicast tree according to the routing tables and explain what happened. - Inspect using Wireshark the PIM-DM packets and the multicast packets (ICMP Echo Request) exchanged during this test and explain them (filter: "pim or icmp"). 4.7. Experiment 7: Multicast sender terminates the transmission. - Stop all multicast senders (if still running). - Display the multicast routing tables and analyze the changes (the routes expire in several minutes).

5. PIM-SM configuration
5.1. Replace PIM-DM by PIM-SM. The configuration commands for RB are listed below (starting in global configuration mode). The configuration of the other routers is similar. ip multicast-routing ip pim rp-address 192.168.2.2 ip pim spt-threshold 100 interface f0/0 ip pim sparse-mode interface f1/0 ip pim sparse-mode interface f2/0 ip pim sparse-mode interface f3/0 ip pim sparse-mode Activate multicast routing globally (already done). Configure a rendezvous point (RP) router (RB). Set the threshold for switching to Shortest Path Tree (SPT) to 100 Kbps (default: switch immediately) Enable multicast routing with PIM-SM for each active interface.

Exit configuration mode. Check the configuration and then save it. 5.2. Examine the current status of PIM-SM by typing the following commands on any router: show ip pim interface show ip pim neighbor show ip mroute - Is PIM-SM enabled on all the interfaces? - Has the router discovered all its PIM-SM neighbors? - What routing information is currently in the multicast routing table?

6. PIM-SM operation
Recall the basic principles of PIM-SM: - PIM-SM builds core-based shared multicast trees. A shared tree connects a core router, also known as rendezvous point (RP) router, to the receivers in a multicast group. Multicast senders are then attached to this tree via the RP router and use it to deliver data to the group. Once a sender is connected to the shared tree, PIM-SM can optimize data delivery from that sender by creating a source-specific tree. - Setup and maintenance of the shared trees is control-driven, meaning that the network uses PIM-SM messages to create and update the tree of a multicast group when receivers join (or leave) that group (independently of the multicast traffic). - Multicast routing information is soft state, which means that it is periodically refreshed (and updated) as long as it is relevant, and then it is automatically removed. - PIM-SM finds a shortest-path multicast tree (rooted at the RP router or at the source) using the existing unicast routing tables and the reverse-path forwarding (RPF) test.

ETTI. Lab: IP multicast (V1.1)

Octavian Catrina, 2013

The purpose of the next experiments is to study these core features of PIM-SM. All multicast senders and receivers are initially stopped. 6.1. Experiment 1: Multicast receivers join the group. Construction of a shared tree with RB as RP. - Capture the traffic at the interface 192.168.5.2 of the router RB. - Start the multicast receiver at host HD. - Display the IGMP status of RD and the multicast routing table of each router. Analyze the changes. Do you see any multicast tree? Explain what happened. Compare with PIM-DM. - Inspect using Wireshark the PIM-SM packets exchanged during the test and explain them (filter: "pim"). - Start the multicast receiver at host HB. - Display the IGMP status of RB and the multicast routing table of each router. Analyze the changes. Explain what happened. 6.2. Experiment 2: Multicast sender starts transmission. Connection to the shared tree via the RP without source-based SPT optimization. - Capture the traffic at the interface 192.168.4.2 of the router RB. - The multicast group 239.2.3.9 has 2 receivers, HB and HD. - Start the multicast sender at host HC. - Display the multicast routing table of each router and analyze the changes. Draw the multicast tree according to the routing tables and explain what happened. Compare with PIM-DM. - Inspect using Wireshark the PIM-SM packets and the multicast packets (ICMP Echo Request) exchanged during this test and explain them (filter: "pim or icmp"). 6.3. Experiment 3: Two multicast senders start transmission. Connection to the shared tree via the RP without source-based SPT optimization. - The multicast group 239.2.3.9 has 2 receivers, HB and HD. - Start the multicast sender at host HC. - Start the multicast sender at host HB. - Display the multicast routing table of each router and analyze the changes. Draw the multicast tree according to the routing tables and explain what happened. Compare with PIM-DM. 6.4. Experiment 4: A multicast receiver joins the multicast group during transmission. - The multicast group 239.2.3.9 has 2 receivers, HB and HD. - Start the multicast sender at host HC. - Start the multicast receiver at host HA. - Display the multicast routing tables and analyze the changes. Draw the multicast tree according to the routing tables and explain what happened. 6.5. Experiment 5: Multicast sender starts transmission. Connection to the shared tree followed by sourcebased SPT optimization. - Modify the configuration of each router to set the SPT threshold to 0 using the following commands: configure terminal ip pim spt-threshold 0 - Capture the traffic at the interfaces 192.168.5.1 and 192.168.7.2 of the router RD. - The multicast group 239.2.3.9 has now 3 receivers, HA, HB and HD. - Start the multicast sender at host HC. - Display the multicast routing table of each router and analyze the changes. Draw the multicast tree according to the routing tables and explain what happened. - Inspect using Wireshark the PIM-SM packets and the multicast packets (ICMP Echo Request) exchanged during this test and explain them (filter: "pim or icmp"). 6.6. Experiment 6: Multicast receivers leave the multicast group. 7

ETTI. Lab: IP multicast (V1.1)

Octavian Catrina, 2013

- Capture the traffic at the interface 192.168.2.2 of the router RB. - Stop the multicast receiver at host HA. - Inspect using Wireshark the PIM-SM packets and the multicast packets (ICMP Echo Request) exchanged during this test and explain them (filter: "pim or icmp"). - Display the multicast routing table of each router and analyze the changes. Draw the multicast tree according to the routing tables and explain what happened. - Stop the multicast receiver on host HD. - Display the multicast routing table of each router and analyze the changes. Draw the multicast tree according to the routing tables and explain what happened. 6.7. Experiment 7: Multicast sender terminates the transmission. - Stop all multicast senders. - Display the multicast routing tables and analyze the changes (routes expire in several minutes).

ETTI. Lab: MPLS TE (V1.1)

Octavian Catrina, 2013

MPLS Traffic Engineering (TE)

Overall objective The purpose of this lab is to study the core protocols and mechanisms used in MPLS Traffic Engineering. 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). These topics are presented in the course material. Review them before the lab. Case study Figure 1 shows the MPLS network used in the lab. It is a simplified service provider network, consisting of 5 core routers, P1,..., P5, and 2 edge routers, PE1 and PE2. The routers run Cisco IOS and are interconnected by Fast Ethernet links. You will carry out a series of experiments on this network, in order to study the main protocols used in MPLS TE in several basic scenarios and router configuration for MPLS TE.

Figure 1. Network configuration used for experiments. Summary of learning objectives You will set up the network shown in Figure 1 and study the following MPLS TE features: Basic configuration of MPLS TE, RSVP-TE, and OSPF-TE. Dynamic tunnel setup (path selected automatically by TE routing).

Automatic tunnel repair by re-routing in case of link or node failures. Explicit tunnel setup (path selected by the network administrator). Tunnel priorities, admission control, and preemption. You will learn how these protocols and mechanisms work by examining the state of the routers using Cisco IOS commands and by studying the exchanged packets using a protocol analyzer.

Overview of MPLS TE features studied in this lab

MPLS Traffic Engineering (TE) and supporting protocols The overall goal of MPLS TE is to map traffic to network resources such that to optimize traffic performance and resource utilization. Another impotent objective is to ensure fast recovery in case of failures. MPLS TE allows to set up LSPs according to certain performance and policy requirements and to allocate the network resources (usually bandwidth) necessary in order to satisfy the performance requirements. These LSPs are called MPLS TE tunnels. MPLS TE uses RSVP-TE as signaling protocol for tunnel setup. RSVP-TE distributes MPLS labels and at the same time allocates resources in each node along the path. 1

ETTI. Lab: MPLS TE (V1.1)

Octavian Catrina, 2013

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 IP routing protocols. MPLS TE uses explicit (sourcerouted) LSPs and routing protocols and algorithms that are able to find paths that satisfy 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. These protocols distribute a set of link attributes necessary for TE (e.g., available bandwidth), besides the usual link metric. The paths are 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 RSVP messages exchanged in order to set up a tunnel from PE1 to PE2. Tunnels are unidirectional. Bidirectional communication requires therefore two tunnels, one for each direction. RSVP-TE sets up a tunnel using downstream on-demand label distribution and explicit routing (i.e., the path is described as a list of intermediate nodes). The setup is initiated by the tunnel's headend router (PE1 in this example), which determines a suitable path using its TE database and a constraint-based routing algorithm, then directs RSVP to set up a tunnel along that path. The PATH message is forwarded downstream 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. Note that the tunnel's headened router performs admission control when it searches for a feasible path across the network. However, it is still necessary to perform admission control at each hop during tunnel setup due to delays between changes in the network and the update of the router's TE database by OSPFTE (the path computed by the headend router might not actually be feasible). 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 FLOWSPEC 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).

Figure 2. Setup of an MPLS TE tunnel from PE1 to PE2 using RSVP-TE. Tunnel priorities and preemption Tunnels are assigned two kinds of priority values: Setup Priority: The priority for taking resources. Holding Priority: The priority for holding resources (hence the priority at which resources are reserved). 2

ETTI. Lab: MPLS TE (V1.1)

Octavian Catrina, 2013

If the bandwidth requested by the PATH message that sets up a new tunnel is available on a link, but it is used by other tunnels with Holding Priority less than its Setup Priority, then some of these tunnels may be preempted to free the necessary bandwidth (beginning with the lowest priority). When a tunnel reservation is preempted, ResvErr and/or PathErr messages are sent to the tunnels tailend and headend, respectively, indicating Policy Control failure.

1. Network setup
The experiments are carried out using the network shown in Figure 1. The network consists of the edge routers PE1 and PE2 and the internal (core) routers P1, ..., P5. The MPLS TE tunnels will be established between the PE routers. 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. Load the initial GNS project. 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 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 IdlePC); 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. 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

2.1. Capture the traffic on the interface f0/0 of router PE1 (link between PE1 and P1). 2.2. Configure OSPF for a single area on all 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.3. Check if OSPF is working properly. Examine the current status using the commands: show ip protocols show ip route Is OSPF running? Wait until the protocol converges (it may take 10s of seconds in this environment). Did all the routers exchange OSPF updates? Do you see routes to all destinations? Do you see multiple routes to some destinations? Why? 2.4. Analyze the captured traffic.

ETTI. Lab: MPLS TE (V1.1)

Octavian Catrina, 2013

Examine the OSPF packets exchanged so far using Wireshark (filter: "ospf"). We haven't enabled TE yet, so you'll see basic OSPF operation, without TE extensions: setup of the OSPF adjacency between PE1 and P1 (synchronization of their initial topological databases), followed by OSPF updates from other routers (until the topological databases are complete). Examine the LSAs in the exchanged OSPF packets and compare them with the network topology. What is the purpose of the periodic OSPF Hello messages? 2.5. Save the configuration of the routers and the GNS project.

3. Enable MPLS TE
We now enable MPLS TE on all routers: MPLS, RSVP, and OSPF traffic engineering extensions. 3.1. Capture the traffic on the interface f0/0 of router PE1 (link between PE1 and P1). 3.2. Enable MPLS TE and RSVP-TE signaling on all routers. The configuration commands for PE1 are listed below (similar for the other routers, enable MPLS TE and RSVP-TE on all interfaces).
mpls traffic-eng tunnels interface f0/0 mpls traffic-eng tunnels ip rsvp bandwidth 10000 Enable MPLS TE on the device. Enable MPLS TE on interface f0/0. Enable RSVP on the interface and specify the max bandwidth available for reservation (Kbps).

3.3. Configure OSPF for TE on all routers (and all interfaces). 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. Examine the MPLS TE status using the commands: show mpls interfaces show mpls traffic-eng topology brief show mpls traffic-eng topology Is MPLS TE enabled on all interfaces? Do you see a complete TE database with all links and their TE attributes? How was this TE database created and for what purpose? 3.5. Examine the RSVP status using the commands: show ip rsvp interface show ip rsvp Is RSVP-TE enabled on all interfaces? 3.6. 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 Updates? Compare the link state in the TE Updates with the Router LSAs in the Updates captured earlier. 3.7. Save the configuration of the routers and the GNS project.

ETTI. Lab: MPLS TE (V1.1)

Octavian Catrina, 2013

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

In this section we set up an 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. All links have sufficient bandwidth for this tunnel. We do not configure a TE metric on the links, so path computation will use the default OSPF metric (which is equal to 1 for Fast Ethernet links). Thus, our tunnel will use the path PE1-P1-P2-P3-PE2.

Figure 3. Dynamic MPLS TE tunnel from PE1 to PE2 (Tunnel 0). 4.1. Continue capturing the traffic on the interface f0/0 of router PE1 (link between PE1 and P1). 4.2. Configure on PE1 a dynamic MPLS TE tunnel to PE2 using the commands listed below.
interface tunnel0 ip unnumbered loopback0 tunnel destination 10.10.2.2 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 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.

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

4.4. Examine the current status of the tunnel (PE and P routers) using the commands: show mpls traffic-eng tunnels brief show mpls traffic-eng tunnels Is the tunnel configured correctly? Is it working correctly? What is the tunnel's path? 4.5. Examine the current status of RSVP (PE and P routers) using the commands: show ip rsvp reservation Is the bandwidth required by the tunnel reserved on all the links of the path? 4.6. Examine the change in the MPLS TE database (PE and P routers) using the commands: show mpls traffic-eng topology 5

ETTI. Lab: MPLS TE (V1.1)

Octavian Catrina, 2013

What has changed after establishing the tunnel? How was the information updated? 4.7. Examine the changes in the routing table of PE1 using the commands: show ip route show ip route 10.10.2.2 How are the IP packets routed to PE2? Which of the commands used for tunnel configuration is responsible for this? 4.8. Analyze the captured traffic using Wireshark. Examine the RSVP-TE packets exchanged after configuring the tunnel (filter: "rsvp"). You should see the initial PATH and RESV messages used to set up the tunnel, followed by periodic PATH/RESV 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 PATH/RESV messages? Examine the OSPF packets exchanged after configuring the tunnel. You should see additional OSPF Update messages containing TE LSAs. Examine the contents of these TE LSAs. What changed with respect to the TE LSAs examined before setting up the tunnel? What is the purpose of these OSPF Update messages? 4.9. Examine the MPLS forwarding table of the routers using the command: show mpls forwarding-table Does it show an entry for our tunnel? 4.10. Test connectivity between PE1 and PE2. Execute on PE1 the command: ping 10.10.2.2 source 10.10.2.1 Examine the exchanged ICMP messages using Wireshark. Are the ICMP requests delivered via the tunnel? Why? What happens to the ICMP replies? Why?

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

We carry out now several experiments to see how MPLS-TE behaves when a link or a node on the tunnel's path fails (Figure 4).

Figure 4. Repair of Tunnel 0 after link (P2 f0/0) or node (P2) failure. 5.1. Capture the traffic on the interface f0/0 of PE1 and interface f0/0 of PE2. 6

ETTI. Lab: MPLS TE (V1.1)

Octavian Catrina, 2013

5.2. Test recovery by automatic re-routing in case of link failure. Execute on PE1 the command: ping 10.10.2.2 source 10.10.2.1 repeat 200 Then shut down the interface f0/0 of P2 (link between P1 and P2): interface f0/0 shutdown You should see a temporary loss of connectivity followed by recovery after a short time interval (<10 sec); you can then terminate ping using Ctrl-Shift-6. 5.3. Examine how the tunnel has changed (on PE and P routers) using the commands: show mpls traffic-eng tunnels 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.4. Examine how the routing table has changed (on PE1) using the commands: show ip route 10.10.2.2 show ip route What has changed after the failure of the link between P1 and P2? 5.5. Analyze using Wireshark the captured traffic. Examine the OSPF and RSVP-TE packets exchanged when the tunnel is re-routed (filter: "ospf or rsvp"). Figure out how the tunnel was re-routed in this scenario: Which router detected the failure? How was the information about the link failure distributed within the network? Which router initiated the re-routing? How was the re-routing achieved? What happened to the bandwidth reservations that are no longer used? 5.6. Activate the interface you have shut down (no shutdown). Examine again the status of the tunnel and the routing table using the commands listed above. Is there any change after the recovery of the link between P1 and P2? 5.7. Re-optimization of the tunnel paths is scheduled by default every 3600 seconds. Therefore, although the interface f0/0 of P2 is again operational, the network still uses the re-routed non-optimal path for our tunnel. 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.8. Test recovery by automatic re-routing in case of node failure. Execute on PE1 the command: ping 10.10.2.2 source 10.10.2.1 repeat 200 Then suspend router P2 using GNS (right-click on the router, then select "Suspend"). You should see a temporary loss of connectivity followed by recovery after a longer time interval. 5.9. Examine the status of the tunnel and the routing table using the commands listed above. You should see that the tunnel was re-routed again on the alternate non-optimal path. Figure out how the re-routing was 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 initiated the re-routing? How was the re-routing achieved? 5.10. Re-start the router P2 using GNS (right-click on the router, then select "Start"). Re-optimize the paths and verify the result (tunnel, routing table). 7

ETTI. Lab: MPLS TE (V1.1)

Octavian Catrina, 2013

5.11. Analyze using Wireshark the captured traffic. Examine the RSVP-TE messages exchanged in order to re-route the tunnel on the optimal path after executing the re-optimization command. Is the re-routing procedure break-after-make or make-after-break?

6. Configure an explicit (alternate) tunnel from PE1 to PE2

We now configure an alternate tunnel from PE1 to PE2 via the (non-optimal) path P1, P4, P5, and P3 as an explicitly routed tunnel, with the path selected by the network administrator (Figure 5).

Figure 5. Additional tunnel (Tunnel 1) from PE1 to PE2 with explicit path specified by configuration. 6.1. Capture the traffic on interface f0/0 of router PE1. 6.2. Configure on router PE1 an explicit tunnel to PE2 using the commands listed below.
interface tunnel1 ip unnumbered loopback0 tunnel destination 10.10.2.2 tunnel mode tunnel mpls tunnel mpls tunnel mpls name LSP1 mpls traffic-eng traffic-eng priority 2 2 traffic-eng bandwidth 1000 traffic-eng path-option 1 explicit Configure tunnel 1 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. Set the tunnel's bandwidth to 1000 Kbps. Configure the path option for tunnel1 as explicit path LSP1 (to be defined later).

6.3. Configure on PE1 the explicit path LSP1, via P1, P4, P5, and P3, using the commands listed below.
ip explicit-path name LSP1 next-address 10.10.0.2 next-address 10.10.0.18 next-address 10.10.0.26 next-address 10.10.0.21 next-address 10.10.0.14

Configure the explicit path LSP1. Configure the next-hops on the path (P1, P4, P5, P3, PE2).

Another way to specify the explicit path LSP1 for our network topology is shown below: 8

ETTI. Lab: MPLS TE (V1.1) ip explicit-path name LSP1 exclude-address 10.10.1.2

Octavian Catrina, 2013

Configure LSP1 explicit path Explicit path that avoids the router P2 (to be determined by the router).

6.4. Verify the configuration and save it. 6.5. Examine the current status of the tunnel (PE and P routers) using the commands: show mpls traffic-eng tunnels brief show mpls traffic-eng tunnels tunnel1 Is the tunnel configured correctly? Is it working correctly? What is the tunnel's path? Try also the following command: show mpls traffic-eng tunnels destination 10.10.2.2 6.6. Examine the current status of RSVP (PE and P routers) using the commands: show ip rsvp reservation Is the bandwidth required by the tunnel reserved on all the links of the path? 6.7. Examine the changes in the routing table of PE1 using the commands: show ip route show ip route 10.10.2.2 Is the new tunnel used for routing IP packets to PE2? Why? 6.8. Analyze the captured traffic using Wireshark. Examine the RSVP-TE packets exchanged after setting up tunnel 1. Do you see RSVP messages for both tunnels? Examine the OSPF Updates exchanged after setting up tunnel 1. How is the bandwidth allocation for tunnel 1 reported in the TE LSAs?

7. Test admission control, tunnel priority, and pre-emption

We'll now make some experiments to test admission control and pre-emption by establishing an additional tunnel from PE1 to PE2, as shown in Figure 6.

Figure 6. Additional tunnel (Tunnel 2) from PE1 to PE2 with 9 Mbps. 9

ETTI. Lab: MPLS TE (V1.1)

Octavian Catrina, 2013

7.1. Capture the traffic on interface f0/0 of PE1 and interface f0/0 of PE2. 7.2. Configure on PE1 a dynamic MPLS TE tunnel to PE2 as described in Section 4, with the following configuration parameters: tunnel number 2, bandwidth 9 Mbps, setup priority 3, holding priority 3. 7.3. Examine the status of tunnel 2 using the commands: show mpls traffic-eng tunnels show ip rsvp reservation Is tunnel 2 configured correctly? Is it working properly? What happened? (In Cisco IOS the constraint-based routing algorithm is called PCALC - Path Calculation.) 7.4. Modify the priorities of tunnel 2 as follows: setup priority 0, holding priority 0. 7.5. Examine again the status of tunnel 2 using the commands: show mpls traffic-eng tunnels show ip rsvp reservation Is tunnel 2 working properly? What happened to tunnel 1? Why? 7.6. Analyze the captured traffic using Wireshark. Examine the RSVP-TE packets exchanged after setting up tunnel 2. Explain what happened. 7.7. Modify the maximum reservable bandwidth from 10 Mbps to 20 Mbps on the bottleneck links, i.e., the following interfaces: PE1 f0/0 and P3 f0/0. 7.8. Examine again the status of the tunnels using the commands: show mpls traffic-eng tunnels show ip rsvp reservation What happened to tunnel 1? Why?

10

ETTI. Lab: MPLS VPN (V2.1)

Octavian Catrina, 2013

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.

ETTI. Lab: MPLS VPN (V2.1)

Octavian Catrina, 2013

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 MPBGP 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 vpn_a vpn_b RD 1:1 1:2 Import RT 1:1 1:2 Export RT 1:1 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.

ETTI. Lab: MPLS VPN (V2.1)

Octavian Catrina, 2013

Figure 3. End-to-end route propagation. The operation of the control plane 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. 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 MPBGP 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 (LA) 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). 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.

ETTI. Lab: MPLS VPN (V2.1)

Octavian Catrina, 2013

The bottom label (LA) 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. Packet forwarding in MPLS-based 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.

1. Network Setup
We use the network configuration 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 of the routers (using the IOS command "copy run start" or "write") and then save the GNS project. 4

ETTI. Lab: MPLS VPN (V2.1)

Octavian Catrina, 2013

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.
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 adjancencies 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 sucessfully established LDP sessions (Open state) with all its neighbors?

ETTI. Lab: MPLS VPN (V2.1)

Octavian Catrina, 2013

- 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

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 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 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 (and start RIP). Set RIP version 2. Enable RIP on interfaces connected to 172.16.0.0/16.

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). 6

ETTI. Lab: MPLS VPN (V2.1) ip vrf vpn_a rd 1:1 route-target route-target ip vrf vpn_b rd 1:2 route-target route-target

Octavian Catrina, 2013

export 1:1 import 1:1

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.

export 1:2 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 show show show show show ip ip ip ip ip ip vrf vrf detail vrf interfaces route route vrf vpn_a 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. Is this correct? 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 no auto-summary 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.

ETTI. Lab: MPLS VPN (V2.1) address-family ipv4 vrf vpn_b network 172.16.0.0 no auto-summary exit-address-family

Octavian Catrina, 2013 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.
show show show show show show ip ip ip ip ip ip vrf vrf detail vrf interfaces route route vrf vpn_a 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 BGP on PE1 and PE2. Start BGP on PE1 and PE2 and establish a BGP connection between them. The AS number 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 no auto-summary Begin BGP configuration (and start BGP) for AS 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). Use the address of Loopback0 as source address for the connection to this neighbor.

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 both neighbor 10.100.255.4 next-hop-self Begin BGP configuration (and start BGP) for AS 1. Begin configuration for the address family vpnv4. For the BGP connection to 10.100.255.4: enable this address family (vpnv4); send Community attributes; set the Next-Hop attribute to own address.

7.3. Examine the current BGP configuration and status. 8

ETTI. Lab: MPLS VPN (V2.1) sh sh sh sh ip ip ip ip bgp summary bgp all route bgp neighbors

Octavian Catrina, 2013

Is there a BGP session between PE1 and PE2? Do you see all the routes you expected in the routing tables? 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 in VRFs and BGP in order to enable propagation of VPN routes between the CE routers. 8.1. Configure redistribution of BGP routes into RIP 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 redistribution of RIP routes in the VRFs into BGP on 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 auto-summary no synchronization exit-address-family address-family ipv4 vrf vpn_b redistribute rip no auto-summary 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 sh sh sh sh ip ip ip ip ip bgp summary bgp all route route vrf vpn_a 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?

ETTI. Lab: MPLS VPN (V2.1)

Octavian Catrina, 2013

8.4. Save the configuration of the routers (PE1, PE2) and the GNS project.

9. VPN Operation (Data and Control Planes)

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