GETVPN+LISP Lab Guide

Transcription

1 GETVPN+LISP Lab Guide Developers and Lab Proctors This lab was created by: Gregg Schudel, TME LISP Development Team Version 1.0: Created by Gregg Schudel Lab proctor: Gregg Schudel Lab Exercises This lab guide includes the following exercises: Lab Exercise 1: Topology Review, including GETVPN Key Server Components Lab Exercise 2: Deploying LISP Shared Model Virtualization for IPv4 and IPv6 EIDs Lab Exercise 3: Deploying GETVPN with LISP Shared Model Virtualization The Locator/ID Separation Protocol (LISP) implements a new routing architecture via a set of protocols that utilize a level of indirection to separate an IP address into two namespaces: Endpoint Identifiers (EIDs), which are assigned to end-hosts, and Routing Locators (RLOCs), which are assigned to devices (primarily routers) that make up the global routing system. In addition to helping solve routing scalability issues, LISP provides many other benefits, including: simplified, cost-effective multihoming and ingress traffic engineering; multi-address-family support (IPv4 and IPv6); IP address (host) mobility, including session persistence across mobility events; and simplified, highly-scalable network virtualization. The inherent properties of LISP that support multi-homing, multiple address families, host/vm mobility, and virtualization, also make it an ideal architecture for creating highly efficient, AF-agnostic, Virtual Private Networks (VPNs). Existing IOS encryption support provided by the IPsec and GETVPN features can be used directly (in a bolt-on manner) with LISP to build encrypted VPNs. The purpose of this lab is to familiarize you with the configuration of a notional Enterprise VPN deployment using LISP shared model virtualization and GETVPN for encryption. In this lab, IPv4 and IPv6 endpoint identifiers (EIDs) are used at each VPN site, with virtualization (three departmental VPNs), all running over a common IPv4 core. GETVPN is added on a per-vrf and per-address family basis (i.e. IPv4 and IPv6 associated with each VRF is encrypted separately), and redundant Map-Servers and Key Servers are deployed. Multihoming is also included in at some sites. Assumptions: Some understanding of LISP and of GETVPN is assumed. This lab does not focus on the basics of each technology, but rather, focuses on the integration of the two.

2 Lab Topology and Access Every attendee will be given access to a POD including eight Cisco routers. The general baseline topology for the GETVPN+LISP lab is illustrated in Figure 1 below. Lab Topology The baseline topology used for the lab is shown in Figure 1 below. Figure 1. Baseline Topology for the GETVPN+LISP Lab Exercise This baseline topology includes the following elements: The topology includes a Headquarters (HQ) site and three Remote Office sites. o o The HQ site is multihomed using two CPE routers (RTR14 and RTR15), each with a single WAN connection to the IPv4 core network. These CPE routers function as LISP xtrs, as well as MS/MRs for the entire VPN. They also function as GETVPN GMs. The HQ site also hosts two separate CPE routers that function as redundant GETVPN Key Servers (RTR18 /KS1 and RTR19/KS2). One Remote site is also multihomed and uses a single CPE router (RTR16); the other two Remote sites are singled homed to the IPv4 core network (RTR11 and RTR13). All CPE routers at these remote sites function as LISP xtrs, as well as GETVPN GMs. The core network is running IPv4. (Note that if the core network were instead running IPv6, a single configuration change only would be required on each site that being the RLOC address. No other changes to other configurations, including the GETVPN configuration, would be necessary.) Three departmental VPNS are configured at all four sites; each of these VPNs includes both IPv4 and IPv6 site prefixes (EIDs). LISP instance-ids are used to provide segmentation. GETVPN is added on a per-vrf and per-address family basis (i.e. IPv4 and IPv6 associated with each VRF is encrypted separately). Redundant Key Servers are also deployed.

3 Lab IP Address Assignment Headquarters (HQ) Site Device WAN Link IPv4 EIDs IPv6 EIDs RTR14 LISP xtr, MSMR GETVPN GM RTR15 LISP xtr, MSMR GETVPN GM /30 Default: /32 IID 0 Default: /24 IID 0 DeptA: /24 IID 1 DeptB: /24 IID 2 DeptC: /24 IID /30 Default: /32 IID 0 Default: /24 IID 0 DeptA: /24 IID 1 DeptB: /24 IID 2 DeptC: /24 IID 3 DeptA: 1:1:14::/64 IID 1 DeptB: 2:2:14::/64 IID 2 DeptC: 3:3:14::/64 IID 3 DeptA: 1:1:14::/64 IID 1 DeptB: 2:2:14::/64 IID 2 DeptC: 3:3:14::/64 IID 3 RTR18 (KS1) /24 - RTR19 (KS2) /24 - Remote Site 1 Device WAN Link IPv4 EIDs IPv6 EIDs RTR11 LISP xtr GETVPN GM /30 Default: /32 IID 0 DeptA: /24 IID 1 DeptB: /24 IID 2 DeptC: /24 IID 3 DeptA: 1:1:11::/64 IID 1 DeptB: 2:2:11::/64 IID 2 DeptC: 3:3:11::/64 IID 3 Remote Site 2 Device WAN Link IPv4 EIDs IPv6 EIDs RTR16 LISP xtr GETVPN GM / /30 Default: /32 IID 0 DeptA: /24 IID 1 DeptB: /24 IID 2 DeptC: /24 IID 3 DeptA: 1:1:16::/64 IID 1 DeptB: 2:2:16::/64 IID 2 DeptC: 3:3:16::/64 IID 3 Remote Site 3 Device WAN Link IPv4 EIDs IPv6 EIDs RTR13 LISP xtr GETVPN GM /30 Default: /32 IID 0 DeptA: /24 IID 1 DeptB: /24 IID 2 DeptC: /24 IID 3 DeptA: 1:1:13::/64 IID 1 DeptB: 2:2:13::/64 IID 2 DeptC: 3:3:13::/64 IID 3 Core Router 12 Device WAN Link IPv4 EIDs IPv6 EIDs RTR12 (core) / / / / / / Notes: All WAN Link IP addressing has been preconfigured and all links are up. The Key Servers KS1 and KS2, and the core router (RTR12) are also fully preconfigured.

4 Lab Exercise 1: Topology Review, Including GETVPN Key Server Components Exercise Description As the intention of the overall GETVPN+LISP Lab is to familiarize you with the fundamentals, configuration and management of a notional Enterprise VPN deployment that incorporates LISP with shared model virtualization and GETVPN. This exercise (Exercise 1) reviews the overall topology and addressing used within the lab. Exercise Objective By completing this exercise, you will learn the functions, baseline configurations, and forwarding characteristics of each router in the topology. This will provide you with knowledge of this topology that is required to complete the LISP deployment exercise that follows. Lab Exercise Steps Step 0 Headquarters LISP Site Review - Review the IPv4 and IPv6 EID addressing and the IPv4 WAN addressing for the Headquarters LISP Site, which includes the routers RTR14 and R15, as well as the Key Servers RTR18 and RTR19. The Headquarters LISP Site is multi-homed and includes two CPE routers, RTR14 and R15, which function as LISP xtrs, LISP Map-Server/Map-Resolvers, and as GETVPN Group Members (GMs). The Headquarters LISP Site also includes routers RTR18 and RTR19, which function as redundant Key Servers (KSs) for GETVPN. RTR14 and RTR15 are configured with three VRFs, DeptA, DeptB, and DeptC, each serving both the IPv4 and IPv6 address space. For example, on RTR14: RTR14-xTR#show run ---<skip>--- vrf definition DeptA address-family ipv4 -address-family address-family ipv6 -address-family vrf definition DeptB address-family ipv4 -address-family address-family ipv6 -address-family vrf definition DeptC address-family ipv4 -address-family address-family ipv6 -address-family The addressing and routing for RTR14 is shown below. Ethernet0/0 is the WAN interface and has the IPv4 address /30. This serves as one of the LISP RLOCs for this multihomed site. (The WAN link for RTR15 serves as the other RLOC

5 for this multihomed site.) The interface Ethernet0/1 includes 3 subinterfaces, and each is within one of the VRFs highlighted above. These subinterfaces are for the IPv4 and IPv6 EID prefixes contained within this LISP site. (Note that these EID prefixes match those given in the table at the beginning of this Lab Guide.) Interface Ethernet0/2 provides the connectivity to one of the GETVPN Key Servers, KS1 in this case. The IPv4 prefix /24 is also in EID space at this LISP site. Loopback0 is used as a reference/management address. One additional notable attribute is the default route for all egress traffic. Since this site is using LISP, only the default route is required. RTR14-xTR#show run begin Loop interface Loopback0 ip address interface Ethernet0/0 ip address interface Ethernet0/1 no ip address interface Ethernet0/1.1 encapsulation dot1q 1 native vrf forwarding DeptA ip address ipv6 address 1:1:14::1/64 interface Ethernet0/1.2 encapsulation dot1q 2 vrf forwarding DeptB ip address ipv6 address 2:2:14::1/64 interface Ethernet0/1.3 encapsulation dot1q 3 vrf forwarding DeptC ip address ipv6 address 3:3:14::1/64 interface Ethernet0/2 ip address interface Ethernet0/3 no ip address shutdown ---<skip>--- ip route The addressing and routing for RTR15 is similar to that of RTR14 and is shown as follows. In the case of RTR15, the IPv4 prefix associated with Ethernet0/ /24 is the EID space for the Key Server KS2. RTR15-xTR#show run begin Loop interface Loopback0 ip address interface Ethernet0/0 ip address interface Ethernet0/1 no ip address

6 interface Ethernet0/1.1 encapsulation dot1q 1 native vrf forwarding DeptA ip address ipv6 address 1:1:14::2/64 interface Ethernet0/1.2 encapsulation dot1q 2 vrf forwarding DeptB ip address ipv6 address 2:2:14::2/64 interface Ethernet0/1.3 encapsulation dot1q 3 vrf forwarding DeptC ip address ipv6 address 3:3:14::2/64 interface Ethernet0/2 ip address interface Ethernet0/3 no ip address shutdown ---<skip>--- ip route The addressing and routing for RTR18 (KS1) is shown as follows. (The full configuration of RTR18 (KS1) will be reviewed in Lab Exercise 3 when GETVPN is added to LISP for encryption.) RTR18-KS1#show run ---<skip>--- interface Ethernet0/0 ip address <skip>--- ip route The addressing and routing for RTR19 (KS2) is shown as follows. (The full configuration of RTR19 (KS2) will be reviewed in Lab Exercise 3 when GETVPN is added to LISP for encryption.) RTR19-KS2#show run ---<skip>--- interface Ethernet0/0 ip address <skip>--- ip route

7 Step 1 Remote LISP Site 1 Review Review the IPv4 and IPv6 EID addressing and the IPv4 WAN addressing for Remote LISP Site 1, which includes router RTR11. Remote LISP Site 1 is single-homed and includes one CPE router, RTR11, which functions as a LISP xtrs and as GETVPN GM. RTR11 is configured with three VRFs, DeptA, DeptB, and DeptC, each serving both the IPv4 and IPv6 address space. The addressing and routing for RTR11 is shown below. Ethernet0/0 is the WAN interface and has the IPv4 address /30. This serves as the LISP RLOC for this site. The interfaces Loopback1, Loopback2, and Loopback3 are used, as is typically done in lab environments, to hold down the IPv4 and IPv6 EID prefixes contained within this LISP site. Each Loopback is within one of the VRFs highlighted above. (Note that these EID prefixes match those given in the table at the beginning of this Lab Guide.) Loopback0 is used as a reference/management address. One additional notable attribute is the default route for all egress traffic. Since this site is using LISP, only the default route is required. RTR11-xTR#show run ---<skip>--- vrf definition DeptA address-family ipv4 -address-family address-family ipv6 -address-family vrf definition DeptB address-family ipv4 -address-family address-family ipv6 -address-family vrf definition DeptC address-family ipv4 -address-family address-family ipv6 -address-family ---<skip>--- interface Loopback0 ip address interface Loopback1 vrf forwarding DeptA ip address ipv6 address 1:1:11::1/64 interface Loopback2 vrf forwarding DeptB ip address ipv6 address 2:2:11::1/64 interface Loopback3 vrf forwarding DeptC ip address ipv6 address 3:3:11::1/64 interface Ethernet0/0 ip address

8 ---<skip>--- ip route Step 2 Remote LISP Site 3 Review Review the IPv4 and IPv6 EID addressing and the IPv4 WAN addressing for Remote LISP Site 3, which includes router RTR13. Remote LISP Site 3 is single-homed and includes one CPE router, RTR13, which function as a LISP xtrs and as GETVPN GM. RTR13 is configured with three VRFs, DeptA, DeptB, and DeptC, each serving both the IPv4 and IPv6 address space. The addressing and routing for RTR13 is shown below. Ethernet0/0 is the WAN interface and has the IPv4 address /30. This serves as the LISP RLOC for this site. The interfaces Loopback1, Loopback2, and Loopback3 are used, as is typically done in lab environments, to hold down the IPv4 and IPv6 EID prefixes contained within this LISP site. Each Loopback is within one of the VRFs highlighted above. (Note that these EID prefixes match those given in the table at the beginning of this Lab Guide.) Loopback0 is used as a reference/management address. One additional notable attribute is the default route for all egress traffic. Since this site is using LISP, only the default route is required. RTR13-xTR#show run ---<skip>--- vrf definition DeptA address-family ipv4 -address-family address-family ipv6 -address-family vrf definition DeptB address-family ipv4 -address-family address-family ipv6 -address-family vrf definition DeptC address-family ipv4 -address-family address-family ipv6 -address-family ---<skip>--- interface Loopback0 ip address interface Loopback1 vrf forwarding DeptA ip address ipv6 address 1:1:13::1/64 interface Loopback2 vrf forwarding DeptB ip address ipv6 address 2:2:13::1/64 interface Loopback3

9 vrf forwarding DeptC ip address ipv6 address 3:3:13::1/64 interface Ethernet0/0 ip address <skip>--- ip route Step 3 Remote LISP Site 2 Review Review the IPv4 and IPv6 EID addressing and the IPv4 WAN addressing for Remote LISP Site 2, which includes router RTR16. Remote LISP Site 2 is multihomed but includes only one CPE router, RTR16, which functions as a LISP xtrs and as GETVPN GM. RTR16 is configured with three VRFs, DeptA, DeptB, and DeptC, each serving both the IPv4 and IPv6 address space. The addressing and routing for RTR16 is shown below. Ethernet0/0 and Ethernet01 are the WAN interfaces (RTR16 is multihomed), and have the IPv4 addresses /30 and /30, respectively. These serve as the LISP RLOCs for this site. The interfaces Loopback1, Loopback2, and Loopback3 are used, as is typically done in lab environments, to hold down the IPv4 and IPv6 EID prefixes contained within this LISP site. Each Loopback is within one of the VRFs highlighted above. (Note that these EID prefixes match those given in the table at the beginning of this Lab Guide.) Loopback0 is used as a reference/management address. One additional notable attribute is the default routes for all egress traffic. Since this site is using LISP, only the default routes are required. RTR16-xTR#show run ---<skip>--- vrf definition DeptA address-family ipv4 -address-family address-family ipv6 -address-family vrf definition DeptB address-family ipv4 -address-family address-family ipv6 -address-family vrf definition DeptC address-family ipv4 -address-family address-family ipv6 -address-family ---<skip>--- interface Loopback0 ip address interface Loopback1 vrf forwarding DeptA ip address ipv6 address 1:1:16::1/64

10 interface Loopback2 vrf forwarding DeptB ip address ipv6 address 2:2:16::1/64 interface Loopback3 vrf forwarding DeptC ip address ipv6 address 3:3:16::1/64 interface Ethernet0/0 ip address interface Ethernet0/1 ip address <skip>--- ip route ip route Step 4 Core Router Review Review the IPv4 IPv4 WAN addressing for Core router, RTR12. RTR12-core, as is typically the case in lab environments, is used to simulate an entire core network. The IPv4 addresses are shown below. Because all other routers are directly connected, no additional routing information is needed for reachability. RTR12-core#show run ---<skip>--- interface Ethernet0/0 ip address interface Ethernet0/1 ip address interface Ethernet0/2 ip address interface Ethernet0/3 ip address interface Ethernet1/0 ip address interface Ethernet1/1 ip address RTR12-core# From RTR12, you should only be able to ping any of the WAN/RLOC interfaces for RTR14, RTR15, RTR11, RTR13, and RTR16. Examples are shown below. Obviously, none of the IPv4 or IPv6 LISP EID prefixes are reachable from the core. RTR12-core#ping Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to , timeout is 2 seconds: Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms RTR12-core#ping Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to , timeout is 2 seconds: Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms RTR12-core#ping Type escape sequence to abort.

11 Sending 5, 100-byte ICMP Echos to , timeout is 2 seconds: Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/6 ms RTR12-core#ping Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to , timeout is 2 seconds: Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms RTR12-core#ping Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to , timeout is 2 seconds: Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms RTR12-core#ping Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to , timeout is 2 seconds: Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms RTR12-core# The above ping tests demonstrate one of the basic principles of LISP that being locator/id separation. This inherent property makes LISP an ideal routing architecture for supporting virtual private networks. End of Exercise: You have successfully completed this exercise. Proceed to next section.

12 Lab Exercise 2: Deploying LISP Shared Model Virtualization for IPv4 and IPv6 EIDs Exercise Description This exercise (Exercise 2) will familiarize you with the configuration of LISP shared model virtualization. Recalling that LISP implements Locator/ID separation to create two namespaces - EIDs and RLOCs, it is easy to see that LISP can consider both EID and RLOC namespaces for virtualization. Either or both can be virtualized. Associating a LISP Instance-ID (IID) to an EID VRF enables EID virtualization. IIDs are numerical tags that are used to maintain EID address space segmentation in both the control plane and data plane. EID namespace virtualization is referred to in LISP as shared model because multiple, distinct EID namespaces, as segmented by VRFs and IIDs, are sharing a common RLOC namespace, as illustrated in Figure 2 below. Notice in Figure 3 that a LISP0.x virtual interface is automatically created for each IID. Thus, as shown in Figure 2, IID 1 is associated with LISP0.1, IID2 is associated with LISP0.2, and IID3 is associated with LISP0.3. (This will also be important when crypto-maps are added to the configuration.) Figure 2. LISP shared model virtualization showing three separate EID namespaces, segmented by LISP instance-ids associated with EID VRFs, and sharing a single, IPv4 RLOC namespace. In this exercise, each of the LISP Site routers will be configured to support three departmental VRFs: DeptA, DeptB, and DeptC. Each VPN will also serving IPv4 and IPv6 address space. You likely noticed that each VRF uses the same, overlapping IPv4 address space. This is possible because of the LISP IID that will be associated with each namespace to provide segmentation. The IPv6 address space used within each VRF is unique, however. Exercise Objective By completing this exercise, you will learn the configuration details required to enable LISP shared model virtualization. Lab Exercise Steps Step 5 Headquarters LISP Site Configuration The Headquarters LISP Site is multihomed and includes two CPE routers, RTR14 and R15, which function as LISP xtrs, LISP Map-Server/Map-Resolvers, and as GETVPN Group Members (GMs). The Headquarters LISP Site also includes routers RTR18 and RTR19, which function as redundant Key Servers (KSs) for GETVPN. In this step, you will configure the LISP Map-Server services, as well as LISP xtr services on RTR14 and RTR15. The relevant information for the HQ LISP site is shown in Figure 3 below.

13 Figure 3. Relevant topology and addressing for the HQ LISP Site Configure RTR14 and RTR15 for LISP Map-Server services. The configuration for the Map-Server is identical on both routers. The configuration for the map-server functions is as follows. Apply this to both RTR14 and RTR15. RTR14 and RTR15 router lisp site HQ authentication-key hq-pswd eid-prefix /24 eid-prefix /24 eid-prefix /32 eid-prefix /32 eid-prefix instance-id /24 eid-prefix instance-id 1 1:1:14::/64 eid-prefix instance-id /24 eid-prefix instance-id 2 2:2:14::/64 eid-prefix instance-id /24 eid-prefix instance-id 3 3:3:14::/64 site Site11 authentication-key site11-pswd eid-prefix /32 eid-prefix instance-id /24 eid-prefix instance-id 1 1:1:11::/64 eid-prefix instance-id /24 eid-prefix instance-id 2 2:2:11::/64 eid-prefix instance-id /24 eid-prefix instance-id 3 3:3:11::/64 site Site13 authentication-key site13-pswd eid-prefix /32 eid-prefix instance-id /24 eid-prefix instance-id 1 1:1:13::/64 eid-prefix instance-id /24 eid-prefix instance-id 2 2:2:13::/64 eid-prefix instance-id /24 eid-prefix instance-id 3 3:3:13::/64 site Site16 authentication-key site16-pswd

14 eid-prefix /32 eid-prefix instance-id /24 eid-prefix instance-id 1 1:1:16::/64 eid-prefix instance-id /24 eid-prefix instance-id 2 2:2:16::/64 eid-prefix instance-id /24 eid-prefix instance-id 3 3:3:16::/64 ipv4 map-server ipv4 map-resolver ipv6 map-server ipv6 map-resolver Configure RTR14 and RTR15 for LISP xtr services for their IPv4 and IPv6 EID prefixes. The configurations for both xtr are similar differing only in the local Loopback used for management (loop0). The LISP xtr configurations for RTR14 and RTR15 are as follows. RTR14 router lisp locator-set HQ-RLOC priority 1 weight priority 1 weight 50 eid-table default instance-id 0 database-mapping / priority 1 weight 1 database-mapping / priority 1 weight 1 eid-table vrf DeptA instance-id 1 database-mapping /24 locator-set HQ-RLOC database-mapping 1:1:14::/64 locator-set HQ-RLOC eid-table vrf DeptB instance-id 2 database-mapping /24 locator-set HQ-RLOC database-mapping 2:2:14::/64 locator-set HQ-RLOC eid-table vrf DeptC instance-id 3 database-mapping /24 locator-set HQ-RLOC database-mapping 3:3:14::/64 locator-set HQ-RLOC no ipv4 map-cache-persistent ipv4 itr map-resolver ipv4 itr map-resolver ipv4 itr ipv4 etr map-server key hq-pswd ipv4 etr map-server key hq-pswd ipv4 etr no ipv6 map-cache-persistent ipv6 itr map-resolver ipv6 itr map-resolver ipv6 itr ipv6 etr map-server key hq-pswd ipv6 etr map-server key hq-pswd ipv6 etr

15 RTR15 router lisp locator-set HQ-RLOC priority 1 weight priority 1 weight 50 eid-table default instance-id 0 database-mapping / priority 1 weight 1 database-mapping / priority 1 weight 1 eid-table vrf DeptA instance-id 1 database-mapping /24 locator-set HQ-RLOC database-mapping 1:1:14::/64 locator-set HQ-RLOC eid-table vrf DeptB instance-id 2 database-mapping /24 locator-set HQ-RLOC database-mapping 2:2:14::/64 locator-set HQ-RLOC eid-table vrf DeptC instance-id 3 database-mapping /24 locator-set HQ-RLOC database-mapping 3:3:14::/64 locator-set HQ-RLOC no ipv4 map-cache-persistent ipv4 itr map-resolver ipv4 itr map-resolver ipv4 itr ipv4 etr map-server key hq-pswd ipv4 etr map-server key hq-pswd ipv4 etr no ipv6 map-cache-persistent ipv6 itr map-resolver ipv6 itr map-resolver ipv6 itr ipv6 etr map-server key hq-pswd ipv6 etr map-server key hq-pswd ipv6 etr Several configuration details are worth noting. 1. The Map-Server configuration is identical on both RTR14 and RTR The xtrs are using the locator-set command to specify the RLOCs for the entire LISP site (i.e., both RLOC interfaces for RTR14 and RTR15). Using the locator-set construct reduces the comply of the database-mapping configurations that follow it. 3. The local loopback0 interface and Key Server EID prefix are configured in the default (global) table and use the local RLOC only for connectivity. 4. All other VRF-related EID prefixes are reachable via both RLOCs and hence are associated with the configured locator-set. At this point, the HQ LISP Site should be active and registering to both Map-Servers. Verify this by reviewing the status of the LISP sites registering to each Map-Server. (RTR14 is shown; RTR15 is similar.)

16 RTR14 RTR14-xTR#show lisp site LISP Site Registration Information Site Name Last Up Who Last Inst EID Prefix Register Registered ID HQ 00:00:44 yes /24 00:00:07 yes /24 00:00:44 yes /32 00:00:07 yes /32 00:00:30 yes /24 00:00:29 yes :1:14::/64 00:00:31 yes /24 00:00:05 yes :2:14::/64 00:00:55 yes /24 00:00:26 yes :3:14::/64 Site11 never no /32 never no /24 never no :1:11::/64 never no /24 never no :2:11::/64 never no /24 never no :3:11::/64 Site13 never no /32 never no /24 never no :1:13::/64 never no /24 never no :2:13::/64 never no /24 never no :3:13::/64 Site16 never no /32 never no /24 never no :1:16::/64 never no /24 never no :2:16::/64 never no /24 never no :3:16::/64 RTR14-xTR# Step 6 Remote LISP Site 1 Configuration Remote LISP Site 1 is single-homed and includes one CPE router, RTR11, which functions as a LISP xtrs and as GETVPN GM. In this step, you will configure the LISP xtr services on RTR11. The relevant information for the Remote LISP Site 1 is shown in Figure 4 below. Figure 4. Relevant topology and addressing for Remote LISP Site 1

17 Configure RTR11 for LISP xtr services for IPv4 and IPv6 EID prefixes. The LISP xtr configuration for RTR11 is as follows. RTR11 router lisp locator-set Site11-RLOC IPv4-interface Ethernet0/0 priority 1 weight 1 eid-table default instance-id 0 database-mapping /32 locator-set Site11-RLOC eid-table vrf DeptA instance-id 1 database-mapping /24 locator-set Site11-RLOC database-mapping 1:1:11::/64 locator-set Site11-RLOC eid-table vrf DeptB instance-id 2 database-mapping /24 locator-set Site11-RLOC database-mapping 2:2:11::/64 locator-set Site11-RLOC eid-table vrf DeptC instance-id 3 database-mapping /24 locator-set Site11-RLOC database-mapping 3:3:11::/64 locator-set Site11-RLOC no ipv4 map-cache-persistent ipv4 itr map-resolver ipv4 itr map-resolver ipv4 itr ipv4 etr map-server key site11-pswd ipv4 etr map-server key site11-pswd ipv4 etr ipv6 map-server ipv6 map-resolver no ipv6 map-cache-persistent ipv6 itr map-resolver ipv6 itr map-resolver ipv6 itr ipv6 etr map-server key site11-pswd ipv6 etr map-server key site11-pswd ipv6 etr Several configuration details are worth noting. 1. The xtr is using the locator-set command to specify the RLOC for this LISP site. In this case, locator-set is referring to the IPv4 address associated with interface Ethernet0/0. This allows the specification of an RLOC in cases (for example) where the address is not directly configured, such as when DHCP is used to obtain the WAN IP address. Using the locator-set construct reduces the comply of the database-mapping configurations that follow it. 2. The local loopback0 interface is configured in the default (global) table. 3. All other VRF-related EID prefixes are reachable via the RLOC associated with the configured locator-set. At this point, Remote LISP Site 1 should be active and registering to both Map- Servers. This can be verified by reviewing the status of the LISP sites registering to each Map-Server as shown in Step 1 above.

18 Step 7 Remote LISP Site 2 Configuration Remote LISP Site 2 is multihomed but includes only one CPE router, RTR16, which functions as a LISP xtrs and as GETVPN GM. The relevant information for the Remote LISP Site 2 is shown in Figure 5 below. Figure 5. Relevant topology and addressing for Remote LISP Site 2 Configure RTR16 for LISP xtr services for IPv4 and IPv6 EID prefixes. The LISP xtr configuration for RTR16 is as follows. RTR16 router lisp locator-set Site16-RLOC priority 1 weight priority 1 weight 50 eid-table default instance-id 0 database-mapping /32 locator-set Site16-RLOC eid-table vrf DeptA instance-id 1 database-mapping /24 locator-set Site16-RLOC database-mapping 1:1:16::/64 locator-set Site16-RLOC eid-table vrf DeptB instance-id 2 database-mapping /24 locator-set Site16-RLOC database-mapping 2:2:16::/64 locator-set Site16-RLOC eid-table vrf DeptC instance-id 3 database-mapping /24 locator-set Site16-RLOC database-mapping 3:3:16::/64 locator-set Site16-RLOC no ipv4 map-cache-persistent ipv4 itr map-resolver ipv4 itr map-resolver ipv4 itr ipv4 etr map-server key site16-pswd ipv4 etr map-server key site16-pswd ipv4 etr ipv6 map-server ipv6 map-resolver no ipv6 map-cache-persistent

19 ipv6 itr map-resolver ipv6 itr map-resolver ipv6 itr ipv6 etr map-server key site16-pswd ipv6 etr map-server key site16-pswd ipv6 etr Several configuration details are worth noting. 1. The xtr is using the locator-set command to specify the two RLOCs for this LISP site. Using the locator-set construct reduces the comply of the database-mapping configurations that follow it. 2. The local loopback0 interface is configured in the default (global) table. 3. All other VRF-related EID prefixes are reachable via the RLOC associated with the configured locator-set. At this point, Remote LISP Site 2 should be active and registering to both Map- Servers. This can be verified by reviewing the status of the LISP sites registering to each Map-Server as shown in Step 1 above. Step 8 Remote LISP Site 3 Configuration Remote LISP Site 3 is single-homed and includes one CPE router, RTR13, which functions as a LISP xtrs and as GETVPN GM. In this step, you will configure the LISP xtr services on RTR13. The relevant information for the Remote LISP Site 3 is shown in Figure 6 below. Figure 6. Relevant topology and addressing for Remote LISP Site 3 Configure RTR13 for LISP xtr services for IPv4 and IPv6 EID prefixes. The LISP xtr configuration for RTR13 is as follows. RTR13 router lisp locator-set Site13-RLOC IPv4-interface Ethernet0/0 priority 1 weight 1 eid-table default instance-id 0 database-mapping /32 locator-set Site13-RLOC eid-table vrf DeptA instance-id 1 database-mapping /24 locator-set Site13-RLOC

20 database-mapping 1:1:13::/64 locator-set Site13-RLOC eid-table vrf DeptB instance-id 2 database-mapping /24 locator-set Site13-RLOC database-mapping 2:2:13::/64 locator-set Site13-RLOC eid-table vrf DeptC instance-id 3 database-mapping /24 locator-set Site13-RLOC database-mapping 3:3:13::/64 locator-set Site13-RLOC no ipv4 map-cache-persistent ipv4 itr map-resolver ipv4 itr map-resolver ipv4 itr ipv4 etr map-server key site13-pswd ipv4 etr map-server key site13-pswd ipv4 etr ipv6 map-server ipv6 map-resolver no ipv6 map-cache-persistent ipv6 itr map-resolver ipv6 itr map-resolver ipv6 itr ipv6 etr map-server key site13-pswd ipv6 etr map-server key site13-pswd ipv6 etr Several configuration details are worth noting. 1. The xtr is using the locator-set command to specify the RLOC for this LISP site. In this case, locator-set is referring to the IPv4 address associated with interface Ethernet0/0. This allows the specification of an RLOC in cases (for example) where the address is not directly configured, such as when DHCP is used to obtain the WAN IP address. Using the locator-set construct reduces the comply of the database-mapping configurations that follow it. 2. The local loopback0 interface is configured in the default (global) table. 3. All other VRF-related EID prefixes are reachable via the RLOC associated with the configured locator-set. At this point, Remote LISP Site 3 should be active and registering to both Map- Servers. This can be verified by reviewing the status of the LISP sites registering to each Map-Server as shown in Step 1 above. Step 9 LISP Shared Model Virtualization Verification At this point in the Lab, LISP should be fully operational. A number of options are available to verify proper configuration and operation. Some of these are demonstrated below. On each xtr, you can verify the configuration of LISP for each address-family and within each IID using the show ip ipv6 lisp instance-id iid command. For example, on RTR16 (Remote LISP Site 2) observe the following: RTR16-xTR#show ip lisp Information applicable to all EID instances: Router-lisp ID: 0 Locator table: default Ingress Tunnel Router (ITR): enabled Egress Tunnel Router (ETR): enabled Proxy-ITR Router (PITR):

21 Proxy-ETR Router (PETR): Map Server (MS): Map Resolver (MR): Delegated Database Tree (DDT): ITR Map-Resolver(s): , ETR Map-Server(s): , xtr-id: 0x6AA6BD2D-0x2853B967-0x71C2B7B7-0xC5591B03 site-id: unspecified ITR Solicit Map Request (SMR): accept and process Max SMRs per map-cache entry: 8 more specifics Multiple SMR suppression time: 20 secs ETR accept mapping data:, verify ETR map-cache TTL: 1d00h Locator Status Algorithms: RLOC-probe algorithm: LSB reports: process IPv4 RLOC minimum mask length: /0 IPv6 RLOC minimum mask length: /0 Map-cache limit: 1000 Map-cache activity check period: 60 secs Persistent map-cache: RTR16-xTR#show ip lisp instance-id 1 Instance ID: 1 Router-lisp ID: 0 Locator table: default EID table: vrf DeptA Ingress Tunnel Router (ITR): enabled Egress Tunnel Router (ETR): enabled Proxy-ITR Router (PITR): Proxy-ETR Router (PETR): Map Server (MS): Map Resolver (MR): Delegated Database Tree (DDT): Map-Request source: ITR Map-Resolver(s): , ETR Map-Server(s): (00:00:43), (00:00:56) xtr-id: 0x6AA6BD2D-0x2853B967-0x71C2B7B7-0xC5591B03 site-id: unspecified ITR Solicit Map Request (SMR): accept and process Max SMRs per map-cache entry: 8 more specifics Multiple SMR suppression time: 20 secs ETR accept mapping data:, verify ETR map-cache TTL: 1d00h Locator Status Algorithms: RLOC-probe algorithm: LSB reports: process IPv4 RLOC minimum mask length: /0 IPv6 RLOC minimum mask length: /0 Static mappings configured: 0 Map-cache size/limit: 1/1000 Imported route count/limit: 0/1000 Map-cache activity check period: 60 secs Map-database size/limit: 1/1000 Persistent map-cache: RTR16-xTR#show ip lisp instance-id 2 Instance ID: 2 Router-lisp ID: 0 Locator table: default EID table: vrf DeptB Ingress Tunnel Router (ITR): enabled Egress Tunnel Router (ETR): enabled Proxy-ITR Router (PITR): Proxy-ETR Router (PETR): Map Server (MS): Map Resolver (MR):

22 Delegated Database Tree (DDT): Map-Request source: ITR Map-Resolver(s): , ETR Map-Server(s): (00:00:40), (00:00:25) xtr-id: 0x6AA6BD2D-0x2853B967-0x71C2B7B7-0xC5591B03 site-id: unspecified ITR Solicit Map Request (SMR): accept and process Max SMRs per map-cache entry: 8 more specifics Multiple SMR suppression time: 20 secs ETR accept mapping data:, verify ETR map-cache TTL: 1d00h Locator Status Algorithms: RLOC-probe algorithm: LSB reports: process IPv4 RLOC minimum mask length: /0 IPv6 RLOC minimum mask length: /0 Static mappings configured: 0 Map-cache size/limit: 1/1000 Imported route count/limit: 0/1000 Map-cache activity check period: 60 secs Map-database size/limit: 1/1000 Persistent map-cache: RTR16-xTR#show ip lisp instance-id 3 Instance ID: 3 Router-lisp ID: 0 Locator table: default EID table: vrf DeptC Ingress Tunnel Router (ITR): enabled Egress Tunnel Router (ETR): enabled Proxy-ITR Router (PITR): Proxy-ETR Router (PETR): Map Server (MS): Map Resolver (MR): Delegated Database Tree (DDT): Map-Request source: ITR Map-Resolver(s): , ETR Map-Server(s): (00:00:12), (00:00:31) xtr-id: 0x6AA6BD2D-0x2853B967-0x71C2B7B7-0xC5591B03 site-id: unspecified ITR Solicit Map Request (SMR): accept and process Max SMRs per map-cache entry: 8 more specifics Multiple SMR suppression time: 20 secs ETR accept mapping data:, verify ETR map-cache TTL: 1d00h Locator Status Algorithms: RLOC-probe algorithm: LSB reports: process IPv4 RLOC minimum mask length: /0 IPv6 RLOC minimum mask length: /0 Static mappings configured: 0 Map-cache size/limit: 1/1000 Imported route count/limit: 0/1000 Map-cache activity check period: 60 secs Map-database size/limit: 1/1000 Persistent map-cache: RTR16-xTR#show ipv6 lisp instance-id 1 Instance ID: 1 Router-lisp ID: 0 Locator table: default EID table: vrf DeptA Ingress Tunnel Router (ITR): enabled Egress Tunnel Router (ETR): enabled Proxy-ITR Router (PITR): Proxy-ETR Router (PETR): Map Server (MS): enabled

23 Map Resolver (MR): enabled Delegated Database Tree (DDT): Map-Request source: 1:1:16::1 ITR Map-Resolver(s): , ETR Map-Server(s): (00:00:12), (00:00:50) xtr-id: 0x6AA6BD2D-0x2853B967-0x71C2B7B7-0xC5591B03 site-id: unspecified ITR Solicit Map Request (SMR): accept and process Max SMRs per map-cache entry: 8 more specifics Multiple SMR suppression time: 20 secs ETR accept mapping data:, verify ETR map-cache TTL: 1d00h Locator Status Algorithms: RLOC-probe algorithm: LSB reports: process IPv4 RLOC minimum mask length: /0 IPv6 RLOC minimum mask length: /0 Static mappings configured: 0 Map-cache size/limit: 1/1000 Imported route count/limit: 0/1000 Map-cache activity check period: 60 secs Map-database size/limit: 1/1000 Persistent map-cache: RTR16-xTR#show ipv6 lisp instance-id 2 Instance ID: 2 Router-lisp ID: 0 Locator table: default EID table: vrf DeptB Ingress Tunnel Router (ITR): enabled Egress Tunnel Router (ETR): enabled Proxy-ITR Router (PITR): Proxy-ETR Router (PETR): Map Server (MS): enabled Map Resolver (MR): enabled Delegated Database Tree (DDT): Map-Request source: 2:2:16::1 ITR Map-Resolver(s): , ETR Map-Server(s): (00:00:40), (00:00:04) xtr-id: 0x6AA6BD2D-0x2853B967-0x71C2B7B7-0xC5591B03 site-id: unspecified ITR Solicit Map Request (SMR): accept and process Max SMRs per map-cache entry: 8 more specifics Multiple SMR suppression time: 20 secs ETR accept mapping data:, verify ETR map-cache TTL: 1d00h Locator Status Algorithms: RLOC-probe algorithm: LSB reports: process IPv4 RLOC minimum mask length: /0 IPv6 RLOC minimum mask length: /0 Static mappings configured: 0 Map-cache size/limit: 1/1000 Imported route count/limit: 0/1000 Map-cache activity check period: 60 secs Map-database size/limit: 1/1000 Persistent map-cache: RTR16-xTR#show ipv6 lisp instance-id 3 Instance ID: 3 Router-lisp ID: 0 Locator table: default EID table: vrf DeptC Ingress Tunnel Router (ITR): enabled Egress Tunnel Router (ETR): enabled Proxy-ITR Router (PITR): Proxy-ETR Router (PETR):

24 Map Server (MS): enabled Map Resolver (MR): enabled Delegated Database Tree (DDT): Map-Request source: 3:3:16::1 ITR Map-Resolver(s): , ETR Map-Server(s): (00:00:31), (00:00:46) xtr-id: 0x6AA6BD2D-0x2853B967-0x71C2B7B7-0xC5591B03 site-id: unspecified ITR Solicit Map Request (SMR): accept and process Max SMRs per map-cache entry: 8 more specifics Multiple SMR suppression time: 20 secs ETR accept mapping data:, verify ETR map-cache TTL: 1d00h Locator Status Algorithms: RLOC-probe algorithm: LSB reports: process IPv4 RLOC minimum mask length: /0 IPv6 RLOC minimum mask length: /0 Static mappings configured: 0 Map-cache size/limit: 1/1000 Imported route count/limit: 0/1000 Map-cache activity check period: 60 secs Map-database size/limit: 1/1000 Persistent map-cache: RTR16-xTR# On each xtr, you can verify the IPv4 and IPv6 EID prefixes that the LISP site is registering and authoritative for within each IID using the show ip ipv6 lisp database instance-id iid command. For example, on RTR16 (Remote LISP Site 2) observe the following: RTR16-xTR#show ip lisp database instance-id 0 LISP ETR IPv4 Mapping Database for EID-table default (IID 0), LSBs: 0x3, 1 entries /32, locator-set Site16-RLOC Locator Pri/Wgt Source State /50 cfg-addr site-self, reachable /50 cfg-addr site-self, reachable RTR16-xTR#show ip lisp database instance-id 1 LISP ETR IPv4 Mapping Database for EID-table vrf DeptA (IID 1), LSBs: 0x3, 1 entries /24, locator-set Site16-RLOC Locator Pri/Wgt Source State /50 cfg-addr site-self, reachable /50 cfg-addr site-self, reachable RTR16-xTR#show ip lisp database instance-id 2 LISP ETR IPv4 Mapping Database for EID-table vrf DeptB (IID 2), LSBs: 0x3, 1 entries /24, locator-set Site16-RLOC Locator Pri/Wgt Source State /50 cfg-addr site-self, reachable /50 cfg-addr site-self, reachable RTR16-xTR#show ip lisp database instance-id 3 LISP ETR IPv4 Mapping Database for EID-table vrf DeptC (IID 3), LSBs: 0x3, 1 entries /24, locator-set Site16-RLOC Locator Pri/Wgt Source State /50 cfg-addr site-self, reachable /50 cfg-addr site-self, reachable RTR16-xTR#show ipv6 lisp database instance-id 0

25 % No local database entries configured. RTR16-xTR#show ipv6 lisp database instance-id 1 LISP ETR IPv6 Mapping Database for EID-table vrf DeptA (IID 1), LSBs: 0x3, 1 entries 1:1:16::/64, locator-set Site16-RLOC Locator Pri/Wgt Source State /50 cfg-addr site-self, reachable /50 cfg-addr site-self, reachable RTR16-xTR#show ipv6 lisp database instance-id 2 LISP ETR IPv6 Mapping Database for EID-table vrf DeptB (IID 2), LSBs: 0x3, 1 entries 2:2:16::/64, locator-set Site16-RLOC Locator Pri/Wgt Source State /50 cfg-addr site-self, reachable /50 cfg-addr site-self, reachable RTR16-xTR#show ipv6 lisp database instance-id 3 LISP ETR IPv6 Mapping Database for EID-table vrf DeptC (IID 3), LSBs: 0x3, 1 entries 3:3:16::/64, locator-set Site16-RLOC Locator Pri/Wgt Source State /50 cfg-addr site-self, reachable /50 cfg-addr site-self, reachable RTR16-xTR# On each xtr, you can verify the IPv4 and IPv6 EID prefixes that the LISP site is authoritative for are actually registering by using the lig self ip ipv6 instance-id iid command. For example, on RTR16 (Remote LISP Site 2) observe the following: RTR16-xTR#lig self ipv4 instance-id 0 Mapping information for EID from with RTT 2 msecs /32, uptime: 00:00:08, expires: 23:59:59, via map-reply, self, complete Locator Uptime State Pri/Wgt :00:08 up, self 1/ :00:08 up, self 1/50 RTR16-xTR#lig self ipv4 instance-id 1 Mapping information for EID from with RTT 1 msecs /24, uptime: 00:00:00, expires: 23:59:59, via map-reply, self, complete Locator Uptime State Pri/Wgt :00:00 up, self 1/ :00:00 up, self 1/50 RTR16-xTR#lig self ipv4 instance-id 2 Mapping information for EID from with RTT 1 msecs /24, uptime: 00:00:00, expires: 23:59:59, via map-reply, self, complete Locator Uptime State Pri/Wgt :00:00 up, self 1/ :00:00 up, self 1/50 RTR16-xTR#lig self ipv4 instance-id 3 Mapping information for EID from with RTT 1 msecs /24, uptime: 00:00:00, expires: 23:59:59, via map-reply, self, complete Locator Uptime State Pri/Wgt :00:00 up, self 1/ :00:00 up, self 1/50 RTR16-xTR#lig self ipv6 instance-id 1 Mapping information for EID 1:1:16:: from with RTT 1 msecs 1:1:16::/64, uptime: 00:00:00, expires: 23:59:59, via map-reply, self, complete Locator Uptime State Pri/Wgt :00:00 up, self 1/50

26 :00:00 up, self 1/50 RTR16-xTR#lig self ipv6 instance-id 2 Mapping information for EID 2:2:16:: from with RTT 1 msecs 2:2:16::/64, uptime: 00:00:00, expires: 23:59:59, via map-reply, self, complete Locator Uptime State Pri/Wgt :00:00 up, self 1/ :00:00 up, self 1/50 RTR16-xTR#lig self ipv6 instance-id 3 Mapping information for EID 3:3:16:: from with RTT 1 msecs 3:3:16::/64, uptime: 00:00:00, expires: 23:59:59, via map-reply, self, complete Locator Uptime State Pri/Wgt :00:00 up, self 1/ :00:00 up, self 1/50 RTR16-xTR# Of course, sending traffic between LISP sites provides the best verification of proper configuration and operation. You can verify this by using the ping vrf <vrfname> <dstaddr> source <srcaddr> repeat <count> command. Some examples for RTR16 (Remote LISP Site 2) are shown next: RTR16-xTR#ping vrf DeptA source repeat 10 Type escape sequence to abort. Sending 10, 100-byte ICMP Echos to , timeout is 2 seconds: Packet sent with a source address of Success rate is 100 percent (10/10), round-trip min/avg/max = 6/6/7 ms RTR16-xTR#ping vrf DeptA source repeat 10 Type escape sequence to abort. Sending 10, 100-byte ICMP Echos to , timeout is 2 seconds: Packet sent with a source address of Success rate is 100 percent (10/10), round-trip min/avg/max = 5/6/8 ms RTR16-xTR#ping vrf DeptA source repeat 10 Type escape sequence to abort. Sending 10, 100-byte ICMP Echos to , timeout is 2 seconds: Packet sent with a source address of Success rate is 80 percent (8/10), round-trip min/avg/max = 5/5/6 ms RTR16-xTR#ping vrf DeptB source repeat 10 Type escape sequence to abort. Sending 10, 100-byte ICMP Echos to , timeout is 2 seconds: Packet sent with a source address of Success rate is 80 percent (8/10), round-trip min/avg/max = 5/5/6 ms RTR16-xTR#ping vrf DeptC source repeat 10 Type escape sequence to abort. Sending 10, 100-byte ICMP Echos to , timeout is 2 seconds: Packet sent with a source address of Success rate is 80 percent (8/10), round-trip min/avg/max = 5/5/6 ms RTR16-xTR# RTR16-xTR#ping vrf DeptA 1:1:14::1 source 1:1:16::1 rep 10 Type escape sequence to abort. Sending 10, 100-byte ICMP Echos to 1:1:14::1, timeout is 2 seconds: Packet sent with a source address of 1:1:16::1%DeptA Success rate is 100 percent (10/10), round-trip min/avg/max = 6/6/9 ms RTR16-xTR#ping vrf DeptA 1:1:11::1 source 1:1:16::1 rep 10 Type escape sequence to abort. Sending 10, 100-byte ICMP Echos to 1:1:11::1, timeout is 2 seconds: Packet sent with a source address of 1:1:16::1%DeptA Success rate is 100 percent (10/10), round-trip min/avg/max = 5/6/7 ms RTR16-xTR#ping vrf DeptA 1:1:13::1 source 1:1:16::1 rep 10

27 Type escape sequence to abort. Sending 10, 100-byte ICMP Echos to 1:1:13::1, timeout is 2 seconds: Packet sent with a source address of 1:1:16::1%DeptA. Success rate is 90 percent (9/10), round-trip min/avg/max = 5/5/7 ms RTR16-xTR#ping vrf DeptB 2:2:14::1 source 2:2:16::1 rep 10 Type escape sequence to abort. Sending 10, 100-byte ICMP Echos to 2:2:14::1, timeout is 2 seconds: Packet sent with a source address of 2:2:16::1%DeptB.. Success rate is 80 percent (8/10), round-trip min/avg/max = 5/6/7 ms RTR16-xTR#ping vrf DeptC 3:3:14::1 source 3:3:16::1 rep 10 Type escape sequence to abort. Sending 10, 100-byte ICMP Echos to 3:3:14::1, timeout is 2 seconds: Packet sent with a source address of 3:3:16::1%DeptC.. Success rate is 80 percent (8/10), round-trip min/avg/max = 6/6/9 ms RTR16-xTR# Notice that in some cases, the first or first two packets are lost. These packets were discarded while RTR16 built its map-cache entry for the destination EID prefix. Once this map-cache entry is built, subsequent flows use the cached mapping entry. After pinging various sites, you can use the show ip ipv6 lisp map-cache instanceid iid command to show the contents of the IPv4 or IPv6 map-cache. Some examples for RTR16 (Remote LISP Site 2) are shown next: RTR16-xTR#show ip lisp map-cache instance-id 0 LISP IPv4 Mapping Cache for EID-table default (IID 0), 3 entries /0, uptime: 2d22h, expires: never, via static send map-request Negative cache entry, action: send-map-request /24, uptime: 2d22h, expires: 04:28:55, via map-reply, complete Locator Uptime State Pri/Wgt d22h up 1/ /32, uptime: 00:30:36, expires: 23:30:38, via map-reply, self, complete Locator Uptime State Pri/Wgt :30:36 up, self 1/ :30:36 up, self 1/50 RTR16-xTR#show ip lisp map-cache instance-id 1 LISP IPv4 Mapping Cache for EID-table vrf DeptA (IID 1), 5 entries /0, uptime: 2d22h, expires: never, via static send map-request Negative cache entry, action: send-map-request /24, uptime: 00:18:54, expires: 23:41:46, via map-reply, complete Locator Uptime State Pri/Wgt :18:54 up 1/ /24, uptime: 00:13:05, expires: 23:47:22, via map-reply, complete Locator Uptime State Pri/Wgt :13:05 up 1/ /24, uptime: 00:19:06, expires: 23:41:34, via map-reply, complete Locator Uptime State Pri/Wgt :19:06 up 1/ :19:06 up 1/ /24, uptime: 00:30:28, expires: 23:30:38, via map-reply, self, complete Locator Uptime State Pri/Wgt :30:28 up, self 1/ :30:28 up, self 1/50 RTR16-xTR#show ip lisp map-cache instance-id 2 LISP IPv4 Mapping Cache for EID-table vrf DeptB (IID 2), 3 entries

28 /0, uptime: 2d22h, expires: never, via static send map-request Negative cache entry, action: send-map-request /24, uptime: 00:12:44, expires: 23:47:43, via map-reply, complete Locator Uptime State Pri/Wgt :12:44 up 1/ :12:44 up 1/ /24, uptime: 00:30:28, expires: 23:30:38, via map-reply, self, complete Locator Uptime State Pri/Wgt :30:28 up, self 1/ :30:28 up, self 1/50 RTR16-xTR#show ip lisp map-cache instance-id 3 LISP IPv4 Mapping Cache for EID-table vrf DeptC (IID 3), 3 entries /0, uptime: 2d22h, expires: never, via static send map-request Negative cache entry, action: send-map-request /24, uptime: 00:12:36, expires: 23:47:50, via map-reply, complete Locator Uptime State Pri/Wgt :12:36 up 1/ :12:36 up 1/ /24, uptime: 00:30:28, expires: 23:30:38, via map-reply, self, complete Locator Uptime State Pri/Wgt :30:28 up, self 1/ :30:28 up, self 1/50 RTR16-xTR#show ipv6 lisp map-cache instance-id 1 LISP IPv6 Mapping Cache for EID-table vrf DeptA (IID 1), 5 entries ::/0, uptime: 2d22h, expires: never, via static send map-request Negative cache entry, action: send-map-request 1:1:11::/64, uptime: 00:11:59, expires: 23:48:26, via map-reply, complete Locator Uptime State Pri/Wgt :11:59 up 1/1 1:1:13::/64, uptime: 00:11:16, expires: 23:49:07, via map-reply, complete Locator Uptime State Pri/Wgt :11:16 up 1/1 1:1:14::/64, uptime: 00:12:15, expires: 23:48:11, via map-reply, complete Locator Uptime State Pri/Wgt :12:15 up 1/ :12:15 up 1/50 1:1:16::/64, uptime: 00:30:25, expires: 23:30:40, via map-reply, self, complete Locator Uptime State Pri/Wgt :30:25 up, self 1/ :30:25 up, self 1/50 RTR16-xTR#show ipv6 lisp map-cache instance-id 2 LISP IPv6 Mapping Cache for EID-table vrf DeptB (IID 2), 3 entries ::/0, uptime: 2d22h, expires: never, via static send map-request Negative cache entry, action: send-map-request 2:2:14::/64, uptime: 00:06:47, expires: 23:53:27, via map-reply, complete Locator Uptime State Pri/Wgt :06:47 up 1/ :06:47 up 1/50 2:2:16::/64, uptime: 00:30:28, expires: 23:30:38, via map-reply, self, complete Locator Uptime State Pri/Wgt :30:28 up, self 1/ :30:28 up, self 1/50 RTR16-xTR#show ipv6 lisp map-cache instance-id 3 LISP IPv6 Mapping Cache for EID-table vrf DeptC (IID 3), 3 entries ::/0, uptime: 2d22h, expires: never, via static send map-request Negative cache entry, action: send-map-request 3:3:14::/64, uptime: 00:06:34, expires: 23:53:40, via map-reply, complete Locator Uptime State Pri/Wgt :06:34 up 1/50

29 :06:34 up 1/50 3:3:16::/64, uptime: 00:30:28, expires: 23:30:38, via map-reply, self, complete Locator Uptime State Pri/Wgt :30:28 up, self 1/ :30:28 up, self 1/50 RTR16-xTR# Additional detail can be queried on a per-destination EID basis using the show ip ipv6 cef vrf vrfname dst-eid internal command to show the contents of the IPv4 or IPv6 CEF table. This shows, for example, the hash-bucket distribution for the destination prefix (if multihomed) and the output interface distribution. Some examples for RTR16 (Remote LISP Site 2) are shown next. RTR16-xTR#show ip cef vrf DeptA internal /24, epoch 0, flags default route handler, subtree context, check lisp eligibility, default route, refcount 5, per-destination sharing sources: IPL, LISP subblocks: SC owned: LISP remote EID - locator status bits 0x LISP remote EID: 19 packets 1648 bytes fwd action encap LISP source path list path list B310246C, flags 0x49, 3 locks, per-destination ifnums: LISP0.1(15): , paths path B30F9B90, path list B310246C, share 50/50, type attached nexthop, for IPv4 nexthop LISP0.1, adjacency IP midchain out of LISP0.1, addr B path B30F9CE0, path list B310246C, share 50/50, type attached nexthop, for IPv4 nexthop LISP0.1, adjacency IP midchain out of LISP0.1, addr B output chain chain[0]: loadinfo B426A034, per-session, 2 choices, flags 0083, 5 locks flags: Per-session, for-rx-ipv4, 2buckets 2 hash buckets < 0 > IP midchain out of LISP0.1, addr B IP adj out of Ethernet0/0, addr B3973A48 < 1 > IP midchain out of LISP0.1, addr B IP adj out of Ethernet0/1, addr B Subblocks: None 2 IPL sources [unresolved, active source] Dependent covered prefix type inherit cover /0 ifnums: (none) path B30F9AB0, path list B31023CC, share 1/1, type recursive, for IPv4, flags doesntsource-via, cef-internal, recursive-via-prefix-no-nh recursive via /0<nh: >[IPv4:DeptA], fib B2181BEC, 1 terminal fib, v4:depta: /0 path B30FA300, path list B3102D7C, share 1/1, type special prefix, for IPv4 no route output chain: LISP eligibility check 0xB05C3B8C for IPv4:DeptA, 4 locks <L> PushCounter(LISP: /24) B3C3F790 loadinfo B426A034, per-session, 2 choices, flags 0083, 5 locks flags: Per-session, for-rx-ipv4, 2buckets 2 hash buckets < 0 > IP midchain out of LISP0.1, addr B IP adj out of Ethernet0/0, addr B3973A48 < 1 > IP midchain out of LISP0.1, addr B IP adj out of Ethernet0/1, addr B Subblocks: None <N> no route RTR16-xTR#sh ipv6 cef vrf DeptA 1:1:14::1 internal 1:1:14::/64, epoch 0, flags default route handler, subtree context, check lisp eligibility, default route, refcount 4, per-destination sharing sources: IPL, LISP subblocks: SC owned: LISP remote EID - locator status bits 0x

30 LISP remote EID: 38 packets 6086 bytes fwd action encap LISP source path list path list B3101F1C, flags 0x49, 3 locks, per-destination ifnums: LISP0.1(15): , paths path B30F92D0, path list B3101F1C, share 12/50, type attached nexthop, for IPv6 nexthop LISP0.1, adjacency IPV6 midchain out of LISP0.1, addr B36D6068 path B30F9260, path list B3101F1C, share 50/50, type attached nexthop, for IPv6 nexthop LISP0.1, adjacency IPV6 midchain out of LISP0.1, addr B36D output chain chain[0]: loadinfo B36D6D94, per-session, 2 choices, flags 0085, 5 locks flags: Per-session, for-rx-ipv6, 2buckets 2 hash buckets < 0 > IPV6 midchain out of LISP0.1, addr B36D6068 IP adj out of Ethernet0/0, addr B3973A48 < 1 > IPV6 midchain out of LISP0.1, addr B36D6198 IP adj out of Ethernet0/1, addr B Subblocks: None 2 IPL sources [unresolved, active source] Dependent covered prefix type inherit cover ::/0 ifnums: (none) path B30F9340, path list B3101F6C, share 1/1, type recursive, for IPv6, flags doesntsource-via, cef-internal, recursive-via-prefix-no-nh recursive via ::/0<nh:1:1:14::>[IPv6:DeptA], fib B3517F90, 1 terminal fib, v6:depta:::/0 path B30FA840, path list B3102B9C, share 1/1, type special prefix, for IPv6 no route output chain: LISP eligibility check 0xB05C3A4C for IPv6:DeptA, 4 locks <L> PushCounter(LISP:1:1:14::/64) B3C3F628 loadinfo B36D6D94, per-session, 2 choices, flags 0085, 5 locks flags: Per-session, for-rx-ipv6, 2buckets 2 hash buckets < 0 > IPV6 midchain out of LISP0.1, addr B36D6068 IP adj out of Ethernet0/0, addr B3973A48 < 1 > IPV6 midchain out of LISP0.1, addr B36D6198 IP adj out of Ethernet0/1, addr B Subblocks: None <N> no route RTR16-xTR# End of Exercise: You have successfully completed this exercise. Proceed to next section.

31 Lab Exercise 3: Deploying GETVPN with LISP Shared Model Virtualization Exercise Description This exercise (Exercise 3) will familiarize you with the configuration of GETVPN to add encryption to the LISP shared model virtualization configuration completed in Exercise 2. Existing IOS encryption support provided by the IPsec and GETVPN features can be used directly (in a bolt-on manner) with LISP to build encrypted VPNs. This Lab focuses solely on GETVPN, which uses the Group Domain of Interpretation (GDOI) group key management protocol to create and distribute cryptographic keys and policies to a group of devices. This creates a trusted group and eliminates the need for point-to-point IPsec associations. All group members (GMs) share a common security association (SA), enabling all GMs to decrypt traffic that was encrypted by any other GM. GDOI cryptographic keys and policies are generated by a Key Server (KS), the most important entity in GETVPN. Multiple, cooperative (COOP) KSs are supported to ensure seamless fault recovery. An overview of the GETVPN/GDOI architecture is illustrated in Figure 7 below. Figure 7. GETVPN/GDO Architecture Overview This document focuses solely on the GETVPN+LISP solution that applies the crypto map to the LISP0.x virtual interface created as part of LISP shared model virtualization. This is the most common architecture and provides the most flexibility for applying unique security policies within the resultant VPN environment. When applied to the LISP0.x virtual interface, GETVPN encryption occurs first, followed by LISP encapsulation. The resultant packet construction is illustrated in Figure 8 below. Figure 8. GETVPN+LISP packet construction when the crypto map is applied to the LISP0.x virtual interface.