lisp lab guide

1

LISP Lab Guide

Developers and Lab Proctors Version 1.0 – Created by Gregg Schudel, TME – LISP Team, 05 Sep 2010 Version 1.1 – Updated by Nick Mitchell, Gregg Schudel, 27 Nov 2012 Version 2.0 – Updated by Gregg Schudel, 02 May 2013 Lab proctor: Gregg Schudel and Nick Mitchell

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 and cost-effective multi-homing, including ingress traffic engineering; IP address (host) mobility, including session persistence across mobility events; IPv6 transition support, including incremental deployment of IPv6 using existing IPv4 infrastructure (or IPv4 over IPv6); and simplified, highly-scalable network virtualization.

LISP is deployed primarily in network edge devices. It requires no changes to host stacks, DNS, or local network infrastructure, and little to no major changes to existing network infrastructures.

Lab Exercises Lab participant will learn about the basics of the LISP protocol and a general deployment architecture, as well as general configuration, verification, and troubleshooting concepts.

This lab guide includes the following exercises: • Lab Exercise 1: Topology Review, including LISP Mapping and Proxy Services • Lab Exercise 2: Deploying LISP-to-LISP for IPv4 • Lab Exercise 3: Deploying LISP-to-LISP for IPv6 with IPv4 Locators • Lab Exercise 4: Deploying LISP-to-non-LISP for IPv4 EIDs with IPv4 Locators • Lab Exercise 5: Deploying LISP-to-non-LISP for IPv6 EIDs with IPv4 Locators • Lab Exercise 6: Deploying LISP Multi-Homing with IPv4 Locators • Lab Exercise 7: Deploying LISP Multi-Homing with IPv4 and IPv6 Locators

Lab participants must normally complete these exercises “in order,” starting at Lab Exercise 1, and working through the set. In this version, the option has been added to “jump in” to any Lab Exercise at any time as the starting point. To skip to a specific exercise, issue the following command on R112-xTR and R116-xTR:

RTR112#<start#>

where start# is the desired starting point. That is, if you wish to being at Exercise 3, then indicate this to the system by entering R112-xTR#start3 (and similar on R116-xTR). (Note that starting at Lab Exercise 1 or Lab Exercise 2 results in the same initial configurations.)

2

Lab Topology and Access Every attendee will be given access to a POD including seven Cisco routers.

Lab Topology The base topology used for the lab is shown below. In the topology, routers R111 and R112 make up LISP Site 1, and R116 and R117 make up LISP Site 2. This could represent two different Enterprise sites, or two sites related to one Enterprise network. Router R113 represents the Internet (core). Routers R114 and R115 provide LISP Mapping Services and Proxy Services support, respectively.

3

Lab Exercise 1: Topology Review, Including LISP Mapping Services Components

Exercise Description In Exercise 1, you will explore the basic topology, review the Core configurations, and understand the basic routing of the “underlying” core network. You will also review the LISP configurations on the Map-Server (R114) and Proxy-Ingress/Egress Tunnel Router (R115).

Exercise Objective As the intention of this Lab exercise is to familiarize you with the overall topology, and the core network configurations and routing. The underlying IP connectivity for the lab topology has already been pre-configured. The LISP Map-Server and PxTR have also been pre-configured. 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 deployments that follow.

Lab Exercise Steps Step 1 Review the IPv4 and IPv6 addressing, configurations, and connectivity for LISP Site 1

(routers R111 and R112) and LISP Site 2 (routers R116 and R117). LISP Site 1: • R111 is used as a “host” for LISP EID addresses within LISP Site 1. It will be used later

during ping testing. R111 has four Loopback interfaces, each with an IPv4/32 and IPv6/128 address from the LISP EID address space for Site 1 of 192.168.1.0/24 and 2001:db8:A:1::/64. R111 has one infrastructure link (E0/0) connecting it to R112 with addresses of 172.16.1.1/30 and 2001:db8:a:2::1/64.

R111-Host1#show ip interface brief | exclude un|down Interface IP-Address OK? Method Status Protocol Ethernet0/0 172.16.1.1 YES manual up up Loopback1 192.168.1.1 YES manual up up Loopback2 192.168.1.2 YES manual up up Loopback3 192.168.1.3 YES manual up up Loopback4 192.168.1.4 YES manual up up R111-Host1# R111-Host1#show ipv6 interface brief | exclude un|down|FE Ethernet0/0 [up/up] 2001:DB8:A:2::1 Loopback1 [up/up] 2001:DB8:A:1::1 Loopback2 [up/up] 2001:DB8:A:1::2 Loopback3 [up/up] 2001:DB8:A:1::3 Loopback4 [up/up] 2001:DB8:A:1::4 R111-Host1#

• In later exercises, R112 will be the LISP Ingress Tunnel Router/Egress Tunnel Router

(ITR/ETR) (abbreviated xTR) for LISP Site 1. R112 has three uplinks connecting it to Core router R113, as well as the internal link connecting it to R111. The uplinks to R113 (E1/1, E1/2, and E1/3) will be used as the locators (RLOCs) for LISP in later exercises. Note that Loopback0 is also configured with IPv4 and IPv6 EID addresses; these will be useful for sourcing packets within the EID prefix range during testing in later exercises.

4

R112-xTR#show ip interface brief | exclude admin|un|Int Ethernet0/0 172.16.1.2 YES manual up up Ethernet1/1 10.0.1.2 YES manual up up Ethernet1/2 10.0.2.2 YES manual up up Loopback0 192.168.1.254 YES manual up up R112-xTR# R112-xTR#show ipv6 interface brief | exclude un|down|FE Ethernet0/0 [up/up] 2001:DB8:A:2::2 Ethernet1/1 [up/up] Ethernet1/2 [up/up] Ethernet1/3 [up/up] 2001:DB8:2:3::2 Loopback0 [up/up] 2001:DB8:A:1::254 R112-xTR#

• At this initial stage in the Lab, from R111 and R112 you should only be able to ping any of the

addresses used in internal infrastructure (i.e. 172.16.1.0/24 and 2001:db8:a:2::/64), as well as any of the (soon to be) LISP EIDs (i.e. 192.168.1.1/2/3/4 and /254, and 2001:db8:a:1::1/2/3/4 and :254). From R112, you should also be able to ping any of the 10/8 infrastructure addresses (in the Core). You should not be able to ping the LISP EID space in LISP Site 2, however (192.168.7.0/24). For example:

R112-xTR#ping 10.0.100.2 so 10.0.1.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.100.2, timeout is 2 seconds: Packet sent with a source address of 10.0.1.2 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 6/7/8 ms R112-xTR#ping 10.0.101.2 so 10.0.1.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.101.2, timeout is 2 seconds: Packet sent with a source address of 10.0.1.2 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms R112-xTR#ping 10.0.9.2 so 10.0.1.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.9.2, timeout is 2 seconds: Packet sent with a source address of 10.0.1.2 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms R112-xTR#ping 192.168.7.254 so 192.168.1.254 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.7.254, timeout is 2 seconds: Packet sent with a source address of 192.168.1.254 ..... Success rate is 0 percent (0/5) R112-xTR#

LISP Site 2: • R117 is used as a “host” for LISP EID addresses within LISP Site 2. It will be used later

during ping testing. R117 has four Loopback interfaces, each with an IPv4/32 and IPv6/128 address from the LISP EID address space for Site 2 of 192.168.7.0/24 and 2001:db8:B:1::/64. R117 has one infrastructure link (E0/0) connecting it to R116 with addresses of 172.16.2.1/30 and 2001:db8:b:2::1/64.

R117-Host7#show ip interface brief | exclude un|down Interface IP-Address OK? Method Status Protocol Ethernet0/0 172.16.7.1 YES manual up up Loopback1 192.168.7.1 YES manual up up Loopback2 192.168.7.2 YES manual up up Loopback3 192.168.7.3 YES manual up up

5

Loopback4 192.168.7.4 YES manual up up R117-Host7# R117-Host7#show ipv6 interface brief | exclude un|down|FE Ethernet0/0 [up/up] 2001:DB8:B:2::1 Loopback1 [up/up] 2001:DB8:B:1::1 Loopback2 [up/up] 2001:DB8:B:1::2 Loopback3 [up/up] 2001:DB8:B:1::3 Loopback4 [up/up] 2001:DB8:B:1::4 R117-Host7#

• In later exercises, R116 will be the LISP xTR for LISP Site 2. R116 has one uplink connecting

it to Core router R113, as well as the internal link connecting it to R117. The uplink to R113 (E0/1) will be used as the locator (RLOC) for LISP in later exercises. Note that Loopback0 is also configured with IPv4 and IPv6 EID addresses; these will be useful for sourcing packets within the EID prefix range during testing in later exercises.

R116-xTR#show ip int brief | exc ad|d Ethernet0/0 172.16.7.2 YES NVRAM up up Ethernet0/1 10.0.9.2 YES NVRAM up up Loopback0 192.168.7.254 YES NVRAM up up R116-xTR# R116-xTR#show ipv6 interface brief | exclude un|do|FE Ethernet0/0 [up/up] 2001:DB8:B:2::2 Loopback0 [up/up] 2001:DB8:B:1::254 R116-xTR#

• At this initial stage in the Lab, from R116 and R117 you should only be able to ping any of the

addresses used in internal infrastructure (i.e. 172.16.2.0/24 and 2001:db8:b:2::/64), as well as any of the (soon to be) LISP EIDs (i.e. 192.168.7.1/2/3/4 and /254, and 2001:db8:b:1::1/2/3/4 and :254). From R116, you should also be able to ping any of the 10/8 infrastructure addresses (in the Core). You should not be able to ping the LISP EID space in LISP Site 1, however (192.168.1.0/24). For example:

R116-xTR#ping 10.0.100.2 so 10.0.9.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.100.2, timeout is 2 seconds: Packet sent with a source address of 10.0.9.2 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms R116-xTR#ping 10.0.101.2 so 10.0.9.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.101.2, timeout is 2 seconds: Packet sent with a source address of 10.0.9.2 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms R116-xTR#ping 10.0.1.2 so 10.0.9.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.1.2, timeout is 2 seconds: Packet sent with a source address of 10.0.9.2 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/13 ms R116-xTR#ping 192.168.1.254 so 192.168.7.254 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.254, timeout is 2 seconds: Packet sent with a source address of 192.168.7.254 ..... Success rate is 0 percent (0/5)

6

R116-xTR#

Step 2 Step 3 Review the IPv4 and IPv6 addressing, configurations, and connectivity for the Core

Router, R113. Core Router: • Router R113 serves as a “core” router representing the IPv4 and IPv6 Internet for the LISP

Lab topology. In addition to the connections to LISP xTR R112 and R116, router R113 also has connections to LISP Map-Server/Map-Resolver, R114, and the LISP Proxy Ingress Tunnel Router/Proxy Egress Tunnel Router (PxTR), R115. Router R113 is also configured with two loopback interfaces: Loopback1, which represents an IPv4 “non-LISP” (Internet) host (ping target), and Loopback0, which represents an IPv6 “non-LISP” (Internet) host. These will be used for testing in later exercises.

R3-Core#show ip interface brief | exclude un|down Interface IP-Address OK? Method Status Protocol Ethernet0/0 10.0.100.1 YES NVRAM up up Ethernet0/1 10.0.101.1 YES NVRAM up up Ethernet0/2 10.0.9.1 YES NVRAM up up Ethernet1/1 10.0.1.1 YES NVRAM up up Ethernet1/2 10.0.2.1 YES NVRAM up up Loopback1 10.200.1.1 YES NVRAM up up R3-Core#show ipv6 interface brief | exclude un|down|FE Ethernet0/0 [up/up] 2001:DB8:3:4::1 Ethernet0/1 [up/up] 2001:DB8:3:5::1 Ethernet1/3 [up/up] 2001:DB8:2:3::1 Loopback0 [up/up] 2001:DB8:C5C0::1 Loopback1 [up/up] R3-Core#

• From R113 you should only be able to ping any of the 10/8 infrastructure addresses

including: R112 and R116, and R114, the LISP MS/MR, and R115, the LISP PxTR. You can also ping the IPv6 versions as appropriate.

• As mentioned in the LISP Lab Overview, this lab concentrates on LISP from the Enterprise

perspective; thus the existence of a “LISP Mapping Service Provider” is assumed. Therefore, all of the LISP Mapping Services and Proxy Services have been pre-configured for this lab. As part of that configuration, R113 is configured as a BGP peer with R115, the LISP PxTR. (This is not a “mandatory” requirement. It does, however, represent a “typical” configuration that a PITR would use to advertise LISP EID space into the Core network. It has been included here for completeness.) As discussed in greater detail in later exercises, the PITR advertises coarse aggregates for both IPv4 and IPv6 LISP EID prefixes into the Core (Internet) in order to attract traffic destined for these prefixes. It then LISP-encapsulates this traffic to the LISP sites. That is the purpose of the above BGP configuration.

R3-Core#sh run | sec router bgp router bgp 3 bgp asnotation dot bgp log-neighbor-changes neighbor 10.0.101.2 remote-as 5 neighbor 2001:DB8:3:5::2 remote-as 5 ! address-family ipv4 neighbor 10.0.101.2 activate neighbor 2001:DB8:3:5::2 activate exit-address-family ! address-family ipv6 neighbor 2001:DB8:3:5::2 activate exit-address-family

7

R3-Core#

Step 4 Step 5 Review the IPv4 and IPv6 addressing, configurations, and connectivity for the LISP Map-

Server/Map-Resolver, R114, and the Proxy xTR, R115.

LISP Mapping-Server/Map-Resolver (MSMR): • R114 provides LISP Map-Server/Map-Resolver (MS/MR) functions for the LISP Lab. R114

has one connection to the Core (R113), but it is configured for both IPv4 and IPv6 connectivity.

R114-MSMR#sh ip int br | exc un|do Interface IP-Address OK? Method Status Protocol Ethernet0/0 10.0.100.2 YES manual up up R114-MSMR#sh ipv6 int br | exc un|do|FE Ethernet0/0 [up/up] 2001:DB8:3:4::2 R114-MSMR#

LISP Proxy ITR/ETR (PxTR): • R115 provides LISP Proxy Ingress Tunnel Router/Proxy Egress Tunnel Router (PxTR) for

both IPv4 and IPv6 address families for the LISP Lab. R115 has one connection to the core, R113, but it is configured for both IPv4 and IPv6 connectivity.

R115-PxTR#sh ip int br | exc un|do Interface IP-Address OK? Method Status Protocol Ethernet0/0 10.0.101.2 YES manual up up R115-PxTR#sh ipv6 int br | exc un|do|FE Ethernet0/0 [up/up] 2001:DB8:3:5::2 R115-PxTR#

• From R114 and R115, you should be able to ping any of the 10/8 infrastructure addresses.

Likewise, you should also be able to ping any of the IPv6 versions as appropriate. Step 6 Review the LISP configurations for the LISP MSMR, R114, and the PxTR, R115. LISP Mapping-Server/Map-Resolver (MSMR): • R114 provides LISP Map-Server/Map-Resolver (MS/MR) functions for the LISP Lab. The

required LISP configurations are all pre-built for this lab. Review their configurations now. R114-MSMR#show run | section lisp|ip route|ipv6 route router lisp site site1 description LISP Site 1 - GOLD Lab authentication-key SITE1KEY eid-prefix 192.168.1.0/24 eid-prefix 2001:DB8:A::/48 exit ! site site2 description Site 2 - GOLD Lab authentication-key SITE2KEY eid-prefix 192.168.7.0/24 eid-prefix 2001:DB8:B::/48 exit ! ipv4 map-server ipv4 map-resolver

8

ipv6 map-server ipv6 map-resolver exit ! ip route 0.0.0.0 0.0.0.0 10.0.100.1 ipv6 route ::/0 2001:DB8:3:4::1 R114-MSMR#

• As shown in R114 above, LISP “site” configurations for LISP Site 1 and LISP Site 2 are

specified. These must be configured in order for these sites to properly register and participate in LISP mapping services. Addition details are provided in later exercises.

LISP Proxy ITR/ETR (PxTR): • R115 provides LISP Proxy ITR/ETR (PxTR) functions for the LISP Lab. The LISP

configurations are all pre-built for this lab. Review their configurations now. R115-PxTR#show run | sec router lisp|router bgp|route-map|ip route|ipv6 route router lisp eid-table default instance-id 0 ipv4 route-import map-cache static route-map EID-space ipv6 route-import map-cache static route-map EID-space exit ! ipv4 map-request-source 10.0.101.2 no ipv4 map-cache-persistent ipv4 map-cache-limit 100000 ipv4 proxy-etr ipv4 proxy-itr 10.0.101.2 2001:DB8:3:5::2 ipv4 itr map-resolver 10.0.100.2 ipv6 map-request-source 2001:DB8:3:5::2 no ipv6 map-cache-persistent ipv6 map-cache-limit 100000 ipv6 proxy-etr ipv6 proxy-itr 2001:DB8:3:5::2 10.0.101.2 ipv6 itr map-resolver 10.0.100.2 exit ! router bgp 5 bgp asnotation dot bgp log-neighbor-changes neighbor 10.0.101.1 remote-as 3 neighbor 2001:DB8:3:5::1 remote-as 3 ! address-family ipv4 redistribute static route-map pop-EID neighbor 10.0.101.1 activate no neighbor 2001:DB8:3:5::1 activate exit-address-family ! address-family ipv6 redistribute static route-map pop-EID neighbor 2001:DB8:3:5::1 activate exit-address-family ! ip route 0.0.0.0 0.0.0.0 10.0.101.1 ip route 192.168.0.0 255.255.0.0 Null0 tag 111 ipv6 route 2001:DB8:A::/47 Null0 tag 111 ipv6 route ::/0 2001:DB8:3:5::1 route-map EID-space permit 10 match tag 111 route-map pop-EID permit 10 match tag 111 set origin igp set community 111:5 R115-PxTR#

9

• As shown in R115 above, two important functions are configured on this router. First, the router acts as a Proxy Ingress Tunnel Router (PITR) and Proxy Egress Tunnel Router (PETR). Enabling PETR functions is trivial (one command for each address family). For the PITR functions, however, the PITR must be configured with the EID-prefix space that it is responsible for being a proxy. Second, as described in further detail in later exercises, the PITR must “advertise” coarse-aggregates for the IPv4 and IPv6 LISP EID prefixes into the Core (Internet) in order to attract traffic destined for these prefixes and for which it is acting as a proxy. This is necessary so that traffic from all non-LISP sources that is destined for LISP sites is first “attracted” to the PITR, which will then LISP-encapsulate the traffic to the LISP site. This interworking function provides “day-one” benefit to LISP sites. That is the purpose of the above BGP configuration. (There are other approaches; BGP has been used here.)

Note: In a “public” LISP deployment, a LISP Services Provider provides all mapping and proxy services. This lab assumes such a scenario, and thus, these services have been ‘pre-configured’ to match the lab exercises. In a “private” LISP implementation, the Enterprise typically deploys its own Mapping Services (i.e. Map-Server/Map-Resolver support), and if required, Proxy Services (i.e. Proxy ITR/ETR).

End of Exercise: You have successfully completed this exercise. Proceed to next section.

10

Lab Exercise 2: Deploying LISP-to-LISP for IPv4

Exercise Description In Exercise 2, you will learn to configure the basic elements of LISP by enabling LISP services on the xTRs for LISP Site 1 (R112) and LISP Site 2 (R116), and investigating LISP-to-LISP traffic for IPv4 EID using IPv4 RLOCs.

Exercise Objective Through the course of this exercise, you will learn how to configure basic LISP Ingress/Egress Tunnel Router services (xTRs). You will also gain familiarity with LISP verification steps.

Lab Exercise Steps

Step 1 Configure LISP Site 1 (R112) for IPv4 EIDs. • In this exercise, R112 will only be using the Ethernet1/1 WAN link as its LISP RLOC. (The

other WAN links will be added in later exercises to demonstrate multihoming/ingress TE.) Also, only the IPv4 EID space will be configured in LISP. (The IPv6 EID space will be added in later exercises to demonstrate multi-address family support.)

• Enter LISP configuration mode: R112-xTR#conf t Enter configuration commands, one per line. End with CNTL/Z. R112-xTR(config)#router lisp R112-xTR(config-router-lisp)#

• Configure a “locator-set” and include the Ethernet 1/1 interface as the only RLOC. Include a

priority or “1” and weight of “1” for this RLOC. R112-xTR(config-router-lisp)#locator-set SITE1 R112-xTR(config-router-lisp-locator-set)# 10.0.1.2 priority 1 weight 1 R112-xTR(config-router-lisp-locator-set)#exit R112-xTR(config-router-lisp)#

11

ALTERNATIVE: • When a LISP site has locators that obtain their IP addresses automatically (such as via

DHCP), the locator-set configuration can specify the interface(s) to be associated as the RLOC(s) rather than directly referring to the IP address(es). For example:

R112-xTR(config-router-lisp)#locator-set SITE1 R112-xTR(config-router-lisp-locator-set)# ipv4-interface Ethernet1/1 priority 1 weight 1 R112-xTR(config-router-lisp-locator-set)#exit R112-xTR(config-router-lisp)#

• In the example above, the IPv4 interface assigned to Ethernet1/1 will automatically be

included as the RLOC. If this IP address changes, for example upon DHCP renewal, the xTR will immediately re-register this new RLOC address with the Map-Server.

• Configure the IPv4 EID prefix 192.168.1.0/24 for this ETR within the default (global) routing

table (and no virtualization instance-id), and associate it to the above locator-set: R2-xTR(config-router-lisp)#eid-table default instance-id 0 R2-xTR(config-router-lisp-eid-table)#database-mapping 192.168.1.0/24 locator-set SITE1 R2-xTR(config-router-lisp-eid-table)#exit R2-xTR(config-router-lisp)#

• Enable LISP ITR and ETR services for IPv4. Notice that after the first service is started, a

diagnostic message is displayed indicating this has occurred. R112-xTR(config-router-lisp)#ipv4 itr R112-xTR(config-router-lisp)#ipv4 etr R112-xTR(config-router-lisp)# *Apr 8 00:53:01.044: %LINEPROTO-5-UPDOWN: Line protocol on Interface LISP0, changed

state to up

• Configure the xTR to point to the Map-Server/ Map-Resolver for registration and mapping

resolution. R112-xTR(config-router-lisp)#ipv4 itr map-resolver 10.0.100.2 R112-xTR(config-router-lisp)#ipv4 etr map-server 10.0.100.2 key SITE1KEY R112-xTR(config-router-lisp)#

• Finally, enable the rloc-probing mechanism for determining remote-site locator reachability. R112-xTR(config-router-lisp)#loc-reach-algorithm rloc-probing R112-xTR(config-router-lisp)#end R112-xTR#

• The Map-Server/Map-Resolver (R114) has been preconfigured with this LISP site information.

The authentication key is “SITE1KEY” and must match correctly for registration to succeed. Step 2 Verify that the EID prefix of LISP Site 1 is registered: • Use the command show ip lisp database to verify the state of the LISP database on R112.

Notice that this output matches the configured information. R112-xTR#sh ip lisp database LISP ETR IPv4 Mapping Database for EID-table default (IID 0), LSBs: 0x1, 1 entries 192.168.1.0/24, locator-set SITE1 Locator Pri/Wgt Source State 10.0.1.2 1/1 cfg-addr site-self, reachable R112-xTR#

12

• Use the command show ip lisp map-cache command to display the initial state of the LISP map-cache on R112. Notice that at this point, only the default (always present) map-cache entry exists. This LISP site is not communicating with any other LISP sites yet; no additional map-cache entries are required. Note that the “default” entry (0.0.0.0/0) has an “action” of “send-map-request” which causes the router to automatically query the mapping system for unknown destinations.

R112-xTR#sh ip lisp map-cache LISP IPv4 Mapping Cache for EID-table default (IID 0), 1 entries 0.0.0.0/0, uptime: 00:08:54, expires: never, via static send map-request Negative cache entry, action: send-map-request R112-xTR#

• Use the “lig self ipv4” command to query the Mapping System for R112’s own IPv4 EID

prefix. The command “lig” (LISP Internet Groper) is a tool that can be used to query the LISP mapping system for its current knowledge of a prefix.

R112-xTR#lig self ipv4 Mapping information for EID 192.168.1.0 from 10.0.1.2 with RTT 1 msecs 192.168.1.0/24, uptime: 00:00:00, expires: 23:59:59, via map-reply, self, complete Locator Uptime State Pri/Wgt 10.0.1.2 00:00:00 up, self 1/1 R112-xTR#

• This step verifies that R112 has registering correctly. If R112 were not correctly registering,

lig would not return the EID prefix for this site. • Use the “show ip lisp map-cache” command to see that R112’s own EID prefix is in the

map-cache. R112-xTR#sh ip lisp map-cache LISP IPv4 Mapping Cache for EID-table default (IID 0), 2 entries 0.0.0.0/0, uptime: 00:16:56, expires: never, via static send map-request Negative cache entry, action: send-map-request 192.168.1.0/24, uptime: 00:01:55, expires: 23:58:09, via map-reply, self, complete Locator Uptime State Pri/Wgt 10.0.1.2 00:01:55 up, self 1/1 R112-xTR#

• Notice that this output matches the configured information. IMPORTANT: The existence of

“your own” EID prefix in your (local) map-cache is not required for LISP operations. The above exercise was used only to illustrate the behavior of the LISP control plane, and to verify LISP site registration success.

Note: To illustrate a failure example, where something is wrong in the control plane, consider the case where the wrong key is entered and LISP Site 1 fails registration, the following would be returned on the LISP Site 1 xTR R2 when “lig self ipv4” is entered.

R112-xTR#lig self ipv4 Mapping information for EID 192.168.1.0 from 10.0.100.2 with RTT 1 msecs 192.168.1.0/24, uptime: 00:00:00, expires: 00:00:59, via map-reply, self, forward-native Negative cache entry, action: forward-native R112-xTR#

• If the site was properly registered (and if the control plane is working), we should expect to

receive the correct information in return. In this case, a negative map-reply is returned. (Further verification is possible, if access to the Map-Server is available. This is discussed later in this exercise below.)

13

Step 3 Configure LISP Site 2 (R116) for IPv4 EIDs. • Follow the same procedures as used for LISP Site 1, but use the appropriate RLOC and LISP

EID information for LISP Site 2: R116-xTR(config)#router lisp R116-xTR(config-router-lisp)#locator-set SITE2 R116-xTR(config-router-lisp-locator-set)#10.0.9.2 priority 1 weight 1 R116-xTR(config-router-lisp-locator-set)#exit R116-xTR(config-router-lisp)#eid-table default instance-id 0 R116-xTR(config-router-lisp-eid-table)#database-mapping 192.168.7.0/24 locator-set SITE2 R116-xTR(config-router-lisp-eid-table)#exit R116-xTR(config-router-lisp)#ipv4 itr R116-xTR(config-router-lisp)#ipv4 etr R116-xTR(config-router-lisp)#ipv4 itr map-resolver 10.0.100.2 R116-xTR(config-router-lisp)#ipv4 etr map-server 10.0.100.2 key SITE2KEY R116-xTR(config-router-lisp)#^Z R116-xTR#


The authentication key is “SITE2KEY” and must match correctly for registration to succeed. Step 4 Verify LISP Site 2 information. • Use the command show ip lisp database to verify the state of the LISP database on R116.

Notice that this output matches the configured information. R116-xTR#sh ip lisp database LISP ETR IPv4 Mapping Database for EID-table default (IID 0), LSBs: 0x1, 1 entries 192.168.7.0/24, locator-set SITE2 Locator Pri/Wgt Source State 10.0.9.2 1/1 cfg-addr site-self, reachable R116-xTR#

• Use the command show ip lisp map-cache command to display the initial state of the LISP

map-cache on R116. Notice that at this point, only the default (always present) map-cache entry exists. This LISP site is not communicating with any other LISP sites yet; no additional map-cache entries are required. Note that the “default” entry (0.0.0.0/0) has an “action” of “send-map-request” which causes the router to automatically query the mapping system for unknown destinations.

R116-xTR#sh ip lisp map-cache LISP IPv4 Mapping Cache for EID-table default (IID 0), 1 entries 0.0.0.0/0, uptime: 00:07:53, expires: never, via static send map-request Negative cache entry, action: send-map-request R116-xTR#

• Use the “lig self ipv4” command to query the Mapping System for R116’s own IPv4 EID

prefix. The command “lig” (LISP Internet Groper) is a tool that can be used to query the LISP mapping system for its current knowledge of a prefix. This step verifies that R116 has registering correctly. If R116 were not correctly registering, lig would not return the EID prefix for this site

R116-xTR#lig self ipv4 Mapping information for EID 192.168.7.0 from 10.0.9.2 with RTT 0 msecs 192.168.7.0/24, uptime: 00:00:00, expires: 23:59:59, via map-reply, self, complete Locator Uptime State Pri/Wgt 10.0.9.2 00:00:00 up, self 1/1 R116-xTR#

14

Step 5 Check the Map-Server: • Use the “show lisp site detail” command on the Map-Server (R114) to verify that EID

prefixes of both LISP Sites are registered: R114-MSMR#sh lisp site detail LISP Site Registration Information Site name: site1 Description: LISP Site 1 - GOLD Lab Allowed configured locators: any Allowed EID-prefixes: EID-prefix: 192.168.1.0/24 First registered: 00:10:54 Routing table tag: 0 Origin: Configuration Merge active: No Proxy reply: No TTL: 1d00h State: complete Registration errors: Authentication failures: 0 Allowed locators mismatch: 0 ETR 10.0.2.2, last registered 00:00:41, no proxy-reply, map-notify TTL 1d00h, no merge, hash-function sha1, nonce 0x954597F5-0x859BF9D1 state complete, no security-capability xTR-ID 0x816B8510-0xBEA35091-0x9D01B036-0xBD9EC071 site-ID unspecified Locator Local State Pri/Wgt 10.0.1.2 yes up 1/1 ---<skip>--- Site name: site2 Description: Site 2 - GOLD Lab Allowed configured locators: any Allowed EID-prefixes: EID-prefix: 192.168.7.0/24 First registered: 00:09:59 Routing table tag: 0 Origin: Configuration Merge active: No Proxy reply: No TTL: 1d00h State: complete Registration errors: Authentication failures: 0 Allowed locators mismatch: 0 ETR 10.0.9.2, last registered 00:00:48, no proxy-reply, map-notify TTL 1d00h, no merge, hash-function sha1, nonce 0xCADCE387-0xFF2B9684 state complete, no security-capability xTR-ID 0x046EC371-0xBC7134B0-0x59DED478-0x067155EA site-ID unspecified Locator Local State Pri/Wgt 10.0.9.2 yes up 1/1 ---<skip>--- R114-MSMR#

Step 6 Verify LISP-to-LISP connectivity by pinging LISP Site 2 from LISP Site 1 • Source-ping R116 from R112 using EID loopbacks as source and destination. R112-xTR#ping 192.168.7.254 source 192.168.1.254 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.7.254, timeout is 2 seconds: Packet sent with a source address of 192.168.1.254 ..!!! Success rate is 60 percent (3/5), round-trip min/avg/max = 1/1/1 ms R112-xTR#

• Notice that the first two packets were unsuccessful. This is a “classic” indication that neither

xTR had an existing map-cache entry for the destination. These packets were discarded by

15

R112 and R116 while they built map-cache entries for each other. Once this map-cache entry is built, subsequent flows between any hosts within the full /24 EID prefixes will use the cached mapping entry.

• Use the “show ip lisp map-cache” command on R112 to show that a new map-cache entry

(via map-reply) is now present for LISP Site 2: R112-xTR#sh ip lisp map-cache LISP IPv4 Mapping Cache for EID-table default (IID 0), 2 entries 0.0.0.0/0, uptime: 20:03:11, expires: never, via static send map-request Negative cache entry, action: send-map-request 192.168.7.0/24, uptime: 20:02:48, expires: 04:43:43, via map-reply, complete Locator Uptime State Pri/Wgt 10.0.9.2 20:02:48 up 1/1 R112-xTR#

• Use the “show ip lisp map-cache” command on R116 to show that a new map-cache entry

(via map-reply) is now present for LISP Site 1. R116-xTR#sh ip lisp map-cache LISP IPv4 Mapping Cache for EID-table default (IID 0), 2 entries 0.0.0.0/0, uptime: 20:04:35, expires: never, via static send map-request Negative cache entry, action: send-map-request 192.168.1.0/24, uptime: 20:04:17, expires: 04:42:36, via map-reply, complete Locator Uptime State Pri/Wgt 10.0.1.2 20:04:17 up 1/1 R116-xTR#

• From the host router, R111, use a source-ping again; this time no packet drops will occur: R111-Host1#ping 192.168.7.1 source 192.168.1.1 rep 100 Type escape sequence to abort. Sending 100, 100-byte ICMP Echos to 192.168.7.1, timeout is 2 seconds: Packet sent with a source address of 192.168.1.1 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Success rate is 100 percent (100/100), round-trip min/avg/max = 1/1/1 ms R111-Host1#

• On the LISP xTR R112, use the “show ip lisp forwarding eid remote” command to verify

how many LISP packets were encapsulated by this router, to show many of the LISP attributes about how this local xTR encapsulates packets to the remote EID.

R112-xTR#sh ip lisp forwarding eid remote 192.168.7.1 Prefix Fwd action Locator status bits 192.168.7.0/24 encap 0x00000001 packets/bytes 114/11274 path list B460082C, flags 0x49, 3 locks, per-destination ifnums: LISP0(21): 10.0.9.2 1 path path B45CF1C8, path list B460082C, share 1/1, type attached nexthop, for IPv4 nexthop 10.0.9.2 LISP0, adjacency IP midchain out of LISP0, addr 10.0.9.2 B467E5F8 1 output chain chain[0]: IP midchain out of LISP0, addr 10.0.9.2 B467E5F8 IP adj out of Ethernet1/2,

addr 10.0.2.1 B467E4C8 R112-xTR#

• From the host router, R111, use a sourced traceroute to show the LISP path.

16

R111-Host1#traceroute 192.168.7.1 source 192.168.1.1 Type escape sequence to abort. Tracing the route to 192.168.7.1 VRF info: (vrf in name/id, vrf out name/id) 1 172.16.1.2 0 msec 0 msec 0 msec 2 10.0.2.1 1 msec 7 msec 7 msec 3 10.0.9.2 1 msec 1 msec 0 msec 4 172.16.7.1 1 msec * 0 msec R111-Host1#

• Notice that all hops between the LISP EIDs are visible in the traceroute. (Typically, tunnel

technologies such as GRE and IPsec hide the network elements between tunnel endpoints.) End of Exercise: You have successfully completed this exercise. Proceed to next section.

17

Lab Exercise 3: Deploying LISP-to-LISP for IPv6 with IPv4 Locators

Exercise Description In Exercise 3, you will learn to configure LISP for IPv6 EID’s by enabling IPv6 LISP services on the xTRs for LISP Site 1 (R112) and LISP Site 2 (R116), and investigating LISP-to-LISP traffic for IPv6 EID using IPv4 RLOCs.

Exercise Objective In this exercise, the goal is to understand how to extend LISP functionality to IPv6 EIDs and explore the address family agnostic behavior of LISP.

Lab Exercise Steps Step 1 Configure LISP Site 1 (R112) for IPv6 EIDs. (The RLOC will remain IPv4.) • In this exercise, R112 will be configured to add the IPv6 EID space to the LISP configuration

from Exercise 2. The LISP configuration will continue using Ethernet1/1 WAN link as its LISP IPv4 RLOC.

• Enter LISP configuration mode and configure the IPv6 EID prefix 2001:db8:a::/48 and use the existing IPv4-only locator-set. Enable LISP ITR and ETR services for IPv6. Configure the Map-Resolver and Map-Server to point to and register with (respectively) for this xTR.

R112-xTR(config)#router lisp R112-xTR(config-router-lisp)#eid-table default instance-id 0 R112-xTR(config-router-lisp-eid-table)#database-mapping 2001:db8:a::/48 locator-set SITE1 R112-xTR(config-router-lisp-eid-table)#exit R112-xTR(config-router-lisp)#ipv6 itr R112-xTR(config-router-lisp)#ipv6 etr R112-xTR(config-router-lisp)#ipv6 itr map-resolver 10.0.100.2 R112-xTR(config-router-lisp)#ipv6 etr map-server 10.0.100.2 key SITE1KEY R112-xTR(config-router-lisp)#^Z R112-xTR#

18

• The Map-Server (R114) has been preconfigured with this IPv6 EID LISP site information. The authentication key is “SITE1KEY” and must match correctly for registration to succeed. Note that the IPv4 RLOCs are still used to communicate with the Map-Resolver and Map-Server since this xTR only has IPv4 WAN connectivity.

Step 2 Verify that LISP Site 1 is registered: • Use the “show ipv6 lisp database” and “show ipv6 lisp map-cache” command to verify the

initial state of the LISP database and map-cache on R112. R112-xTR#sh ipv6 lisp database LISP ETR IPv6 Mapping Database for EID-table default (IID 0), LSBs: 0x1, 1 entries 2001:DB8:A::/48, locator-set SITE1 Locator Pri/Wgt Source State 10.0.1.2 1/1 cfg-addr site-self, reachable R112-xTR#sh ipv6 lisp map-cache LISP IPv6 Mapping Cache for EID-table default (IID 0), 1 entries ::/0, uptime: 00:20:09, expires: never, via static send map-request Negative cache entry, action: send-map-request R112-xTR#

• Notice that this information matches that configured in the database-mapping command.

Notice that at this point, only the default (always present) map-cache entry exists. This LISP site is not communicating with any other LISP sites yet; no additional map-cache entries are required. Note that the “default” entry (::/0) has an “action” of “send-map-request” which causes the router to automatically query the mapping system for unknown destinations

• You can use “lig self ipv6” to query the Mapping System for R112’s own IPv6 EID prefix. R112-xTR#lig self ipv6 Mapping information for EID 2001:DB8:A:: from 10.0.1.2 with RTT 0 msecs 2001:DB8:A::/48, uptime: 00:00:00, expires: 23:59:59, via map-reply, self, complete Locator Uptime State Pri/Wgt 10.0.1.2 00:00:00 up, self 1/1 R112-xTR#

• This step verifies that R112 is registering correctly. If R112 were not correctly registering, it

would not return the EID prefix for this site. • Use the “show ipv6 lisp map-cache” command to show that R112’s own IPv6 EID prefix is

now in the map-cache (as a result of “lig”). R112-xTR#sh ipv6 lisp map-cache LISP IPv6 Mapping Cache for EID-table default (IID 0), 2 entries ::/0, uptime: 00:40:10, expires: never, via static send map-request Negative cache entry, action: send-map-request 2001:DB8:A::/48, uptime: 00:02:20, expires: 23:57:45, via map-reply, self, complete Locator Uptime State Pri/Wgt 10.0.1.2 00:02:20 up, self 1/1 R112-xTR#

• Notice that this information matches that configured in the database-mapping command. Step 3 Configure LISP Site 2 (R116) for IPv6 EIDs using the existing IPv4 locators. • Follow the same procedures as used for LISP Site 1, but use the appropriate RLOC and LISP

EID information for LISP Site 2: R116-xTR(config)#router lisp R116-xTR(config-router-lisp)#eid-table default instance-id 0 R116-xTR(config-router-lisp-eid-table)# database-mapp 2001:db8:b::/48 locator-set SITE2

19

R116-xTR(config-router-lisp-eid-table)#exit R116-xTR(config-router-lisp)#ipv6 itr R116-xTR(config-router-lisp)#ipv6 etr R116-xTR(config-router-lisp)#ipv6 itr map-resolver 10.0.100.2 R116-xTR(config-router-lisp)#ipv6 etr map-server 10.0.100.2 key SITE2KEY R116-xTR(config-router-lisp)#^Z


The authentication key is “SITE2KEY” and must match correctly for registration to succeed. Step 4 Verify LISP Site 2 information. • Use the “show ipv6 lisp database” and “show ipv6 lisp map-cache” command to verify the

initial state of the LISP database and map-cache on R6. R116-xTR#sh ipv6 lisp database LISP ETR IPv6 Mapping Database for EID-table default (IID 0), LSBs: 0x1, 1 entries 2001:DB8:B::/48, locator-set SITE2 Locator Pri/Wgt Source State 10.0.9.2 1/1 cfg-addr site-self, reachable R116-xTR#

• Notice that this output matches the configured information. R116-xTR#sh ipv6 lisp map-cache LISP IPv6 Mapping Cache for EID-table default (IID 0), 1 entries ::/0, uptime: 00:30:55, expires: never, via static send map-request Negative cache entry, action: send-map-request R116-xTR#

• Notice that at this point, only the default (always present) map-cache entry exists. This LISP

site is not communicating with any other LISP sites yet; no additional map-cache entries are required. Note that the “default” entry (::/0) has an “action” of “send-map-request” which causes the router to automatically query the mapping system for unknown destinations.

• Use “lig self ipv6” to query the Mapping System for R116’s own IPv6 EID prefix. R116-xTR#lig self ipv6 Mapping information for EID 2001:DB8:B:: from 10.0.9.2 with RTT 1 msecs 2001:DB8:B::/48, uptime: 00:00:00, expires: 23:59:59, via map-reply, self, complete Locator Uptime State Pri/Wgt 10.0.9.2 00:00:00 up, self 1/1 R116-xTR#

• This step verifies that R116 has registering correctly. If R116 were not correctly registering,

lig would not return the EID prefix for this site. Step 5 Check the Map-Server: • Use the “show lisp site” command on the Map-Server (R114) to verify that both LISP Sites

are registered: R114-MSMR#sh lisp site LISP Site Registration Information Site Name Last Up Who Last Inst EID Prefix Register Registered ID site1 00:00:34 yes 10.0.2.2 192.168.1.0/24 00:00:44 yes 10.0.2.2 2001:DB8:A::/48 site2 00:00:41 yes 10.0.9.2 192.168.7.0/24 00:00:32 yes 10.0.9.2 2001:DB8:B::/48 R114-MSMR#

20

Step 6 Verify LISP-to-LISP connectivity by pinging from LISP Site 1 to LISP Site 2: • Source-ping R116 from R112 using the IPv6 EID loopbacks as source and destination. R112-xTR#ping 2001:db8:b:1::254 so 2001:db8:a:1::254 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2001:DB8:B:1::254, timeout is 2 seconds: Packet sent with a source address of 2001:DB8:A:1::254 ..!!! Success rate is 60 percent (3/5), round-trip min/avg/max = 1/1/1 ms R112-xTR#

• Notice that the first two packets were unsuccessful. This is a “classic” indication that neither

xTR had an existing map-cache entry for the destination. These packets were discarded by R112 and R116 while they built map-cache entries for each other. Once this map-cache entry is built, subsequent flows between any hosts within the full /48 EID prefixes will use the cached mapping entry.

• Use the “show ipv6 lisp map-cache” command on R112 to show that a new map-cache

entry (via map-reply) is now present for LISP Site 2: R112-xTR#sh ipv6 lisp map-cache LISP IPv6 Mapping Cache for EID-table default (IID 0), 2 entries ::/0, uptime: 00:00:18, expires: never, via static send map-request Negative cache entry, action: send-map-request 2001:DB8:B::/48, uptime: 00:00:15, expires: 23:59:45, via map-reply, complete Locator Uptime State Pri/Wgt 10.0.9.2 00:00:15 up 1/1 R112-xTR#

• Use the “show ipv6 lisp map-cache” command on R116 to show that a new map-cache

entry (via map-reply) is now present for LISP Site 1. R116-xTR#sh ipv6 lisp map-cache LISP IPv6 Mapping Cache for EID-table default (IID 0), 2 entries ::/0, uptime: 00:01:13, expires: never, via static send map-request Negative cache entry, action: send-map-request 2001:DB8:A::/48, uptime: 00:01:03, expires: 23:58:59, via map-reply, complete Locator Uptime State Pri/Wgt 10.0.1.2 00:01:03 up 1/1 R116-xTR#

• From the host router, R111, use a source-ping again; this time no packet drops will occur: R111-Host1#ping 2001:db8:b:1::1 so 2001:db8:a:1::1 rep 100 Type escape sequence to abort. Sending 100, 100-byte ICMP Echos to 2001:DB8:B:1::1, timeout is 2 seconds: Packet sent with a source address of 2001:DB8:A:1::1 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Success rate is 100 percent (100/100), round-trip min/avg/max = 6/6/8 ms R111-Host1#

• On the LISP xTR R112, use the “show ipv6 lisp forwarding eid remote” command to verify

how many LISP packets were encapsulated by this router, to show many of the LISP attributes about how this local xTR encapsulates packets to the remote EID.

R112-xTR#sh ipv6 lisp forwarding eid remote 2001:db8:b:1::1 Prefix Fwd action Locator status bits 2001:DB8:B::/48 encap 0x00000001 packets/bytes 109/10844 path list B4600A5C, flags 0x49, 3 locks, per-destination ifnums:

21

LISP0(21): 10.0.9.2 1 path path B45CEF28, path list B4600A5C, share 1/1, type attached nexthop, for IPv6 nexthop 10.0.9.2 LISP0, adjacency IPV6 midchain out of LISP0, addr 10.0.9.2 B467E5F8 1 output chain chain[0]: IPV6 midchain out of LISP0, addr 10.0.9.2 B467E5F8 IP adj out of

Ethernet1/2, addr 10.0.2.1 B467E4C8 R112-xTR#

• From the host router, R111, use a sourced traceroute to show the LISP path. R111-Host1#traceroute Protocol [ip]: ipv6 Target IPv6 address: 2001:db8:b:1::1 Source address: 2001:db8:a:1::1 Insert source routing header? [no]: Numeric display? [no]: Timeout in seconds [3]: Probe count [3]: Minimum Time to Live [1]: Maximum Time to Live [30]: Priority [0]: Port Number [0]: Type escape sequence to abort. Tracing the route to 2001:DB8:B:1::1 1 2001:DB8:A:2::2 0 msec 1 msec 1 msec 2 2001:DB8:B:1::254 0 msec 1 msec 1 msec 3 2001:DB8:B:2::1 0 msec 0 msec 0 msec R111-Host1#

• Notice that in this case, only the IPv6 hops are visible. (There is no “interworking” between

IPv4 and IPv6 ICMP.) End of Exercise: You have successfully completed this exercise. Proceed to next section.

22

Lab Exercise 4: Deploying LISP-to-non-LISP for IPv4 EIDs with IPv4 Locators

Exercise Description In Exercise 4, no new LISP configurations are needed on the LISP Site routers. However, this exercise will use the pre-configured LISP Proxy Ingress Tunnel Router (PITR) (R115). During this exercise you will mainly be exploring the functionality implemented by the PITR. This exercise simulates the real-world scenario where an Enterprise site that has converted to LISP also requires access to non-LISP (Internet) sites.

Exercise Objective In this exercise, the goal is to understand the functionality of the LISP PITR in supporting interworking in the “non-LISP to LISP” direction.

Lab Exercise Steps

Step 1 Verify that the Core router (R113) is seeing the IPv4 LISP EID aggregate prefix, and that the LISP PITR is operating correctly. Verify that the PITR has no IPv4 map-cache entries initially.

• Ensure that the Core router (R113) sees the IPv4 LISP EID aggregate prefix (192.168.0.0/16) as being advertised by the LISP PITR (R5):

R113-Core#sh ip route | inc 192.168.0.0 B 192.168.0.0/16 [20/0] via 10.0.101.2, 2d10h R113-Core#

• Notice that the IPv4 LISP EID aggregate 192.168.0.0/16 is advertised by the LISP PITR

(R115). (BGP peering shows this prefix as “via 10.0.101.2”.)

23

• Verify that Core router (R113) has the “non-LISP ping target” configured for this exercise: R113-Core#show ip interface brief | include 10.200.1.1 Loopback1 10.200.1.1 YES NVRAM up up R113-Core#

• In this case, the interface Loopback1 (10.200.1.1) is dedicated as a non-LISP ‘IPv4 ping

target”. • The LISP PITR (R115) operates in a very similar manner as a normal LISP ITR. The main

difference is where an ITR will only LISP-encapsulate packets sourced from its own EID prefixes (as determined by any configured “database-mapping” commands), a PITR will LISP-encapsulate any packets, regardless of source, that are destined to a LISP site. Therefore, a PITR also maintains a LISP map-cache, but does not have LISP database. Rather, the PITR must be “configured” with the EID space it is responsible for “proxying” to LISP sites.

• Prior to sending traffic to the non-LISP address, verify that the PITR LISP map-cache

contains no entries, except the entry for 192.168.0.0/16: R115-PxTR#clear ip lisp map-cache R115-PxTR#sh ip lisp map-cache LISP IPv4 Mapping Cache for EID-table default (IID 0), 1 entries 192.168.0.0/16, uptime: 00:00:03, expires: never, via route-import, send-map-request Negative cache entry, action: send-map-request R115-PxTR#

• Note that the “action” for this map-cache entry is ”send-map-request.” This shows that this

PITR is configured to proxy for the EID address space covered by 192.168.0.0/16, and that, in the absence of any other map-cache entries, it should send a map-request to the configured Map-Resolver to obtain a current EID-to-RLOC mapping.

Step 2 Source ping traffic from LISP xTR R112 to the non-LISP host and review the results. • Clear the ip lisp map-cache on the LISP xTR R112. This gives us a good baseline from

which to begin this exercise. R112-xTR#clear ip lisp map-cache R112-xTR#sh ip lisp map-cache LISP IPv4 Mapping Cache for EID-table default (IID 0), 1 entries 0.0.0.0/0, uptime: 00:00:12, expires: never, via static send map-request Negative cache entry, action: send-map-request R112-xTR#

• Source-ping from LISP xTR R112 using the source IPv4 test EID address 192.168.1.254

and the non-LISP IPv4 destination 10.200.1.1. Review the results. R112-xTR#ping 10.200.1.1 source 192.168.1.254 repeat 100 Type escape sequence to abort. Sending 100, 100-byte ICMP Echos to 10.200.1.1, timeout is 2 seconds: Packet sent with a source address of 192.168.1.254 ..!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Success rate is 98 percent (98/100), round-trip min/avg/max = 1/1/1 ms R112-xTR#

• These results are very similar to the prior examples where the map-cache entry is not already

built. However, in this case, the map-cache entries are built on this router (R112) for the destination, and on the PITR (R115) for the return traffic (back to this site).

• Review the map-cache now added on LISP xTR R112.

24

R112-xTR#sh ip lisp map-cache LISP IPv4 Mapping Cache for EID-table default (IID 0), 2 entries 0.0.0.0/0, uptime: 00:11:15, expires: never, via static send map-request Negative cache entry, action: send-map-request 0.0.0.0/1, uptime: 00:04:34, expires: 00:10:36, via map-reply, forward-native Negative cache entry, action: forward-native R112-xTR#

• In this case, because the destination (10.200.1.1) is determined by the MSMR (R114) to not

be a LISP EID (as would be known by it via a configured “site” command), the MSMR returns a “negative map-reply” (NMR) back to the xTR (R112). The aggregate covered by this NMR is computed by the MSMR to cover the “largest possible block” that does not contain a known LISP EID prefix. In this case (above), you can see that the NMR covers the block 0.0.0.0/1 since for this lab the MSMR only contains two sites – both in the 192.168.0.0/16 range. Note also that the “action” of the negative cache entry is “forward-native” which means these packets are forwarded natively (sent without LISP encapsulation) toward the destination.

• Verify that a map-cache entry has also now been built on the LISP PITR R115 to handle the

return traffic (non-LISP to LISP): R115-PxTR#sh ip lisp map-cache LISP IPv4 Mapping Cache for EID-table default (IID 0), 2 entries 192.168.0.0/16, uptime: 00:56:53, expires: never, via route-import, send-map-request Negative cache entry, action: send-map-request 192.168.1.0/24, uptime: 00:13:46, expires: 23:46:44, via map-reply, complete Locator Uptime State Pri/Wgt 10.0.1.2 00:13:46 up 1/1 R115-PxTR#

• As expected, the PITR (R115) has a map-cache entry that includes the LISP xTR R112 prefix

and its site policy (locators and ingress TE specifications) installed in its map-cache. The PITR uses this map-cache entry to LISP-encapsulate traffic (return echo-reply packets in this case) to LISP xTR R112.

• Check the LISP encapsulation details on the LISP PITR R115: R115-PxTR#sh ip lisp forwarding eid remote 192.168.1.0 Prefix Fwd action Locator status bits 192.168.1.0/24 encap 0x00000001 packets/bytes 98/9800 path list B4672D3C, flags 0x49, 4 locks, per-destination ifnums: LISP0(11): 10.0.1.2 1 path path B44938A8, path list B4672D3C, share 1/1, type attached nexthop, for IPv4 nexthop 10.0.1.2 LISP0, adjacency IP midchain out of LISP0, addr 10.0.1.2 B0A34D08 1 output chain chain[0]: IP midchain out of LISP0, addr 10.0.1.2 B0A34D08 IP adj out of Ethernet0/0,

addr 10.0.101.1 B2977008 R115-PxTR#

• Notice that the LISP PITR R115 has encapsulated packets to the LISP Site 1 xTR R112.


25

Lab Exercise 5: Deploying LISP-to-non-LISP for IPv6 with IPv4 Locators

Exercise Description In Exercise 5, new LISP configurations will be added, and you will be exploring the functionality implemented by the LISP Proxy Egress Tunnel Router (PETR). This exercise simulates the real-world scenario where an Enterprise site that has incorporated LISP as an IPv6 transition mechanism and requires access to non-LISP IPv6 sites. In order for this to work (when LISP sites only have IPv4 WAN connectivity), both PITR and PETR support must exist.

Exercise Objective In this exercise, the goal is to understand the functionality of the LISP PETR (and PITR) in cross address-family interworking support. Specifically in this case, the PETR is used to allow IPv6 EIDs to “hop over” the IPv4 RLOC core. The dual-stacked PETR provides this Address Family “hop over” functionality. The PITR is also dual-stacked and provides the return traffic support.

Lab Exercise Steps

Step 1 Verify that the Core router (R113) is seeing the IPv6 LISP EID aggregate prefix, and that the LISP PITR is operating correctly. Verify that the PITR has no IPv6 map-cache entries initially.

• Ensure that Core router (R113) has the IPv6 LISP EID aggregate prefix (2001:db8:a::/47) as being advertised by the LISP PITR (R115).

R113-Core#sh ipv6 route | inc /47 B 2001:DB8:A::/47 [20/0] R113-Core#

• Notice that the IPv6 LISP EID aggregate 2001:db8:a::/47 is advertised by LISP PITR (R115).

26

• Verify that Core router (R113) has the “non-LISP ping target” configured for this exercise: R113-Core#show ipv6 interface brief | inc Loop|C5 Loopback0 [up/up] 2001:DB8:C5C0::1 R113-Core#

• In this case, Loopback0 (2001:db8:c5c0::1) is dedicated as a non-LISP ‘ping target”. • Verify the LISP PxTR (R115) configuration for both Proxy ITR and Proxy ETR services. R115-PxTR#sh ipv6 lisp Instance ID: 0 Router-lisp ID: 0 Locator table: default EID table: default Ingress Tunnel Router (ITR): disabled Egress Tunnel Router (ETR): disabled Proxy-ITR Router (PITR): enabled RLOCs: 2001:DB8:3:5::2, 10.0.101.2 Proxy-ETR Router (PETR): enabled Map Server (MS): disabled Map Resolver (MR): disabled Delegated Database Tree (DDT): disabled Map-Request source: 2001:DB8:3:5::2 ITR Map-Resolver(s): 10.0.100.2 ---<skip>--- R115-PxTR#

• The LISP PITR (R115) operates in a very similar manner as a normal LISP ITR. The main

difference is where an ITR will only LISP-encapsulate packets sourced from its own EID prefixes (as determined by any configured “database-mapping” commands), a PITR will LISP-encapsulate any packets, regardless of source, that are destined to a LISP site. Therefore, a PITR also maintains a LISP map-cache, but does not have LISP database. Rather, the PITR must be “configured” with the EID space it is responsible for “proxying” to LISP sites.

• Prior to sending traffic to the non-LISP address, verify that the PITR LISP map-cache

contains no entries, except the entry for 2001:db8:a::/47. R115-PxTR#clear ipv6 lisp map-cache R115-PxTR#sh ipv6 lisp map-cache LISP IPv6 Mapping Cache for EID-table default (IID 0), 1 entries 2001:DB8:A::/47, uptime: 00:00:02, expires: never, via route-import, send-map-request Negative cache entry, action: send-map-request R115-PxTR#

• Note that the “action” for this map-cache entry is ”send-map-request.” This shows that this

PITR is configured to proxy for the EID address space covered by 2001:db8:a::/47, and that, in the absence of any other map-cache entries, it should send a map-request to the configured Map-Resolver to obtain a current EID-to-RLOC mapping.

Step 2 Configure LISP xTR R112 and LISP xTR R116 to use the LISP PETR for address family

“hop-over” support. • Configure the LISP xTR R112 to use the LISP PETR. R112-xTR(config)#router lisp R112-xTR(config-router-lisp)#ipv6 use-petr 10.0.101.2 R112-xTR(config-router-lisp)#^Z R112-xTR#

27

• Configure the LISP xTR R116 to use the LISP PETR. R116-xTR(config)#router lisp R116-xTR(config-router-lisp)#ipv6 use-petr 10.0.101.2 R116-xTR(config-router-lisp)#^Z R116-xTR#

• Verify that LISP xTR R112 is configured to use Proxy ETR services. R112-xTR#sh ipv6 lisp Instance ID: 0 Router-lisp ID: 0 Locator table: default EID table: default Ingress Tunnel Router (ITR): enabled Egress Tunnel Router (ETR): enabled Proxy-ITR Router (PITR): disabled Proxy-ETR Router (PETR): disabled Map Server (MS): disabled Map Resolver (MR): disabled Delegated Database Tree (DDT): disabled Map-Request source: 2001:DB8:A:2::2 ITR Map-Resolver(s): 10.0.100.2 ETR Map-Server(s): 10.0.100.2 (00:00:52) xTR-ID: 0xA2EADCF9-0xC09C318D-0x99EC7710-0xD93D3099 site-ID: unspecified ITR use proxy ETR RLOC(s): 10.0.101.2 ---<skip>--- R112-PxTR#

Step 3 Source ping traffic from LISP xTR R112 to the non-LISP host and review the results. • Clear the ipv6 lisp map-cache on the LISP xTR R112. This gives us a good baseline from

which to begin this exercise. R112-xTR#clear ipv6 lisp map-cache R112-xTR#sh ipv6 lisp map-cache LISP IPv6 Mapping Cache for EID-table default (IID 0), 1 entries ::/0, uptime: 00:00:03, expires: never, via static send map-request Negative cache entry, action: send-map-request R112-xTR#

• Source-ping from LISP xTR R112 using the source IPv6 test EID address 2001:db8:a::254

and the non-LISP IPv6 destination 2001:db8:c5c0::1. Review the results. R112-xTR#ping 2001:db8:c5c0::1 source 2001:db8:a:1::254 rep 100 Type escape sequence to abort. Sending 100, 100-byte ICMP Echos to 2001:DB8:C5C0::1, timeout is 2 seconds: Packet sent with a source address of 2001:DB8:A:1::254 ..!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Success rate is 98 percent (98/100), round-trip min/avg/max = 1/1/8 ms R112-xTR#

• These results are very similar to the prior examples where the map-cache entry is not already

built. However, in this case, the map-cache entries are built on this router (R112) for the PETR as the destination, and on the PITR (R115) for the return traffic (back to this site).

• Review the map-cache now added on LISP xTR R112. R112-xTR#sh ipv6 lisp map-cache LISP IPv6 Mapping Cache for EID-table default (IID 0), 2 entries ::/0, uptime: 00:06:38, expires: never, via static send map-request Negative cache entry, action: send-map-request

28

2001:DB8:8000::/33, uptime: 00:00:28, expires: 00:14:32, via map-reply, forward-native Encapsulating to proxy ETR R112-xTR#

• In this case, because the destination (2001:db8:c5c0::1) is determined by the MSMR (R114)

to not be a LISP EID (as would be known to it via a configured “site” command), the MSMR returns a “negative map-reply” (NMR) back to the xTR (R112). The aggregate covered by this NMR is computed by the MSMR to cover the “largest possible block” that does not contain a known LISP EID prefix. In this case (above), you can see that the NMR covers the block 2001:db8:8000::/33. Note also that the “action” of the negative cache entry is “forward-native” which means these packets are forwarded natively. However, since this site only has an IPv4 WAN connection (RLOC), LISP uses the IPv4 RLOC on R112 as an outer header source, and the IPv4 RLOC of the PETR is the outer header destination – and all IPv6 EID packets are LISP-encapsulated over IPv4 to the PETR. The PETR is dual-stacked; it decapsulates the LISP packets and then forwards them natively to the non-LISP target. Return packets are attracted to the dual-stacked PITR, which LISP encapsulates them over IPv4 back to LISP Site 1.

• Verify that a map-cache entry has also now been built on the LISP PITR R115 to handle the

return traffic (non-LISP to LISP): R115-PxTR#sh ipv6 lisp map-cache LISP IPv6 Mapping Cache for EID-table default (IID 0), 2 entries 2001:DB8:A::/47, uptime: 00:07:20, expires: never, via route-import, send-map-request Negative cache entry, action: send-map-request 2001:DB8:A::/48, uptime: 00:01:18, expires: 23:58:44, via map-reply, complete Locator Uptime State Pri/Wgt 10.0.1.2 00:01:18 up 1/1 R115-PxTR#

• As expected, the PITR (R115) has a map-cache entry that includes the LISP xTR R112 prefix

and its site policy (locators and ingress TE specifications) installed in its map-cache. The PITR uses this map-cache entry to LISP-encapsulate traffic (return echo-reply packets in this case) to LISP xTR R112.

• Check the LISP encapsulation details on the LISP PITR R115: R115-PxTR#sh ipv6 lisp forwarding eid remote 2001:db8:a:1::1 Prefix Fwd action Locator status bits 2001:DB8:A::/48 encap 0x00000001 packets/bytes 98/9800 path list B4672DDC, flags 0x49, 4 locks, per-destination ifnums: LISP0(11): 10.0.1.2 1 path path B4493988, path list B4672DDC, share 1/1, type attached nexthop, for IPv6 nexthop 10.0.1.2 LISP0, adjacency IPV6 midchain out of LISP0, addr 10.0.1.2 B0A34BD8 1 output chain chain[0]: IPV6 midchain out of LISP0, addr 10.0.1.2 B0A34BD8 IP adj out of

Ethernet0/0, addr 10.0.101.1 B2977008 R115-PxTR# R115-PxTR#

• Notice that the LISP PITR R115 has encapsulated packets to the LISP Site 1 xTR R112. • Check the LISP encapsulation details on the LISP xTR R112: R112-xTR#sh ipv6 lisp forwarding eid remote 2001:db8:c5c0::1 Prefix Fwd action Locator status bits 2001:DB8:8000::/33 fwd native 0x00000000 packets/bytes 99/8514 path list B460069C, flags 0x49, 3 locks, per-destination ifnums:

29

LISP0(23): 10.0.101.2 1 path path B45CEBA8, path list B460069C, share 1/1, type attached nexthop, for IPv6 nexthop 10.0.101.2 LISP0, adjacency IPV6 midchain out of LISP0, addr 10.0.101.2

B467E5F8 1 output chain chain[0]: IPV6 midchain out of LISP0, addr 10.0.101.2 B467E5F8 IP adj out of

Ethernet1/1, addr 10.0.1.1 B467E728 R112-xTR#

• Notice that the LISP xTR R112 has encapsulated IPv6 EIDs to the LISP PETR located at

10.0.100.2.


30

Lab Exercise 6: Deploying LISP Multihoming with IPv4 Locators Exercise Description

In Exercise 6, you will continue configuring basic LISP elements. In this exercise, you will add a second RLOC interface to the edge router (xTR) at LISP Site 1. This exercise simulates the real-world scenario where an Enterprise site requires additional bandwidth and desires to attain diversity in Service Providers by using multi-homing.

Exercise Objective Through the course of this exercise, you will learn how to configure basic multihoming using LISP, and set an ingress traffic engineering policy for the site. In this case, the site will specify active/active link utilization with 50%/50% load sharing.

Lab Exercise Steps Step 1 Configure LISP Site 1 (R112) for a second IPv4 RLOC. • Ensure that both IPv4 WAN interfaces are “up” (Eth1/1 and Eth1/2) on R112, and that default

routing is set for both interfaces. (This should be the pre-configured state for this Lab. This step simply confirms that current state.)

R112-xTR#show ip interface brief | exc un|down Interface IP-Address OK? Method Status Protocol Ethernet0/0 172.16.1.2 YES manual up up Ethernet1/1 10.0.1.2 YES manual up up Ethernet1/2 10.0.2.2 YES manual up up Loopback0 192.168.1.254 YES manual up up R112-xTR#

31

• Add the default route for interface Eth1/2, which will be added to the LISP locator-set. A default route needs to be added for this interface.

R112-xTR(config)# ip route 0.0.0.0 0.0.0.0 10.0.2.1 R112-xTR(config)#

• Add interface Eth1/2 to the LISP locator-set. Adding this second RLOC allows this xTR to be

multihomed. In this case, specify that ingress traffic to the site should use both links in a 50%/50% active/active load sharing mode.

R112-xTR(config)#router lisp R112-xTR(config-router-lisp)#locator-set SITE1 R112-xTR(config-router-lisp-locator-set)#10.0.2.2 priority 1 weight 1 R112-xTR(config-router-lisp-locator-set)#^Z R112-xTR#

• Now the EID prefixes for which this site is authoritative are associated with two IPv4 RLOCs

(10.0.1.2, and 10.0.2.2), with each give a priority of 1 and a weight of 1. Note: LISP uses the concept of “priority” and “weight” to create a policy that indicates how the site wants to receive traffic destined for its EID prefixes.

o When a LISP site has multiple locators, each locator may be assigned the same or a different priority value between 0 and 255. When multiple locators are assigned different priority values, the priority value alone is used to determine which locator to prefer. A lower value indicates a more preferable path. A value of 255 indicates that the locator must not be used for unicast traffic forwarding.

o When multiple locators have the same priority, they will be used in a load-sharing manner. For a given priority, the weight assigned to each locator is used to determine how to load-share unicast flows amongst each locator. A weight value of between 0 and 100 is used to represent the percentage of traffic to be load-shared to that locator. ** In practice, the router computes the percentage based on the assigned weights. This is required

for failure scenarios where an RLOC may not be available and LISP must re-balance the load-share. (For example, if an xTR has three locators, and then one goes down, the xTR must re-compute the load share. Here is the calculation for this lab.

(weight of this locator) 1 1 ------------------------ --- -- (sum of all weights) (1+1) 2

In the trivial case here, each locator has been given a weight value of “1” which indicates that each locator is to receive 1/2 the traffic flows

Step 2 Verify that LISP Site 1 is now using this new information in its database: • Use the “show ip lisp database” command to verify the LISP database on R112. Notice that

the new information matches the configured database-mapping commands. R112-xTR#sh ip lisp database LISP ETR IPv4 Mapping Database for EID-table default (IID 0), LSBs: 0x3, 1 entries 192.168.1.0/24, locator-set SITE1 Locator Pri/Wgt Source State 10.0.1.2 1/1 cfg-addr site-self, reachable 10.0.2.2 1/1 cfg-addr site-self, reachable R112-xTR#

• Observe the map-cache on LISP xTR (R116) using the command show ip lisp map-cache.

The new mapping policy for R112 should now be available to R116. R116-xTR#sh ip lisp map-cache LISP IPv4 Mapping Cache for EID-table default (IID 0), 2 entries

32

0.0.0.0/0, uptime: 00:48:32, expires: never, via static send map-request Negative cache entry, action: send-map-request 192.168.1.0/24, uptime: 00:29:20, expires: 23:56:03, via map-reply, complete Locator Uptime State Pri/Wgt 10.0.1.2 00:29:20 up 1/1 10.0.2.2 00:29:20 up 1/1 R116-xTR#

• Notice that the IPv4 map-cache on LISP xTR R116 is already updated and using the new

policy from LISP xTR R112. Did this happen? Why or why not? If this did happen: o First, remember that LISP sites only maintain map-cache entries for EIDs that they are

having conversations with. By default, map-cache entries have a TTL of 24-hours. In addition, each map-cache entry will have a “state” of either “active” or “idle” – indicating how recently traffic has actually been flowing towards the remote EID. This can be seen in the detailed output of the command show ip lisp map-cache. For example, on RTR116, observe the details for the remote EID 192.168.1.0/24.

R116-xTR#sh ip lisp map-cache 192.168.1.0/24 LISP IPv4 Mapping Cache for EID-table default (IID 0), 2 entries 192.168.1.0/24, uptime: 00:44:47, expires: 23:59:46, via map-reply, complete Sources: map-reply State: complete, last modified: 00:32:45, map-source: 10.0.2.2 Active, Packets out: 1044 (~ 00:00:14 ago) Locator Uptime State Pri/Wgt 10.0.1.2 00:44:47 up 1/1 Last up-down state change: 00:44:47, state change count: 1 Last route reachability change: never, state change count: 0 Last priority / weight change: never/00:32:45 RLOC-probing loc-status algorithm: Last RLOC-probe sent: 00:00:14 (rtt 1ms) Next RLOC-probe in: 00:00:44 Latched to ITR-RLOC: 10.0.9.2 10.0.2.2 00:44:47 up 1/1 Last up-down state change: 00:44:47, state change count: 1 Last route reachability change: never, state change count: 0 Last priority / weight change: never/never RLOC-probing loc-status algorithm: Last RLOC-probe sent: 00:00:14 (rtt 0ms) Next RLOC-probe in: 00:00:46 Latched to ITR-RLOC: 10.0.9.2 R116-xTR#

o Also notice above that RLOC probing is querying the status of the R112 locators. LISP

xTR R112 also has rloc-probing enabled. When rloc-probing is enabled, an xTR will automatically “inform” the xTRs with which it is currently conversing, as determined by the list of high priority locators in its map-cache, of any changes to its site policy. In this case, when you added the second RLOC to the LISP xTR R112 locator-set, R112 will request that LISP xTR R116 “update” its map-cache entry for R112. R112 does this by sending a “solicit map-request” (SMR) message to R116. An SMR requests that the receiver initiate a normal “map-request” process in order to cause it to update its (now out-of-date) map-cache entry for the changed site.

If this did not happen: o The above discussion assumes of course that a map-cache entry was still present on

R112 for the remote site LISP xTR R116. If a map-cache entry is not present on R112, then R112 will not inform R116 of the change of policy immediately. In this case: a) if R116 also does not have a mapping, it will obtain a new mapping during the normal map-request/map-reply process, or b) if R116 has the old mapping, it will be updated by R112 once R116 and R112 initiate traffic flow and R112 installs a map-cache entry for R116.

• On the LISP xTR R116, ping the LISP xTR R112 EID. Observe that all packets are

successful (assuming that a map-cache entry is available on both xTRs).

33

R116-xTR#ping 192.168.1.254 so 192.168.7.254 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.254, timeout is 2 seconds: Packet sent with a source address of 192.168.7.254 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms R116-xTR#

• On the LISP xTR R116, use the show ip lisp forwarding eid remote command to verify that

LISP encapsulation will utilize both RLOCs on LISP xTR 112. R116-xTR#sh ip lisp forward eid remote 192.168.1.1 Prefix Fwd action Locator status bits 192.168.1.0/24 encap 0x00000003 packets/bytes 4/344 path list B4389BDC, flags 0x49, 3 locks, per-destination ifnums: LISP0(11): 10.0.1.2, 10.0.2.2 2 paths path B3736748, path list B4389BDC, share 1/1, type attached nexthop, for IPv4 nexthop 10.0.1.2 LISP0, adjacency IP midchain out of LISP0, addr 10.0.1.2 B4404780 path B3736198, path list B4389BDC, share 1/1, type attached nexthop, for IPv4 nexthop 10.0.2.2 LISP0, adjacency IP midchain out of LISP0, addr 10.0.2.2 B4404520 1 output chain chain[0]: loadinfo B1BC829C, per-session, 2 choices, flags 0083, 5 locks flags: Per-session, for-rx-IPv4, 2buckets 2 hash buckets < 0 > IP midchain out of LISP0, addr 10.0.1.2 B4404780 IP adj out of Ethernet0/1,

addr 10.0.9.1 B297D648 < 1 > IP midchain out of LISP0, addr 10.0.2.2 B4404520 IP adj out of Ethernet0/1,

addr 10.0.9.1 B297D648 Prefix Fwd action Locator status bits Subblocks: None R116-xTR#

• Notice that the “locator status bits” show 0x00000003, indicating that the remote site (R112)

has two locators, and both are considered “up” and available as destinations for LISP encapsulated packets to reach 192.168.1.0/24. (The hex value 0x00000003 represents the Locator-Status-Bits (LSB) binary value of 0000 00011 which indicates the up/down status (both “up” in this case as indicated by the value “1” in each of the first two bit positions).

• Because LISP load sharing is performed on a per-flow basis using a five-tuple hash of the

source packets, in order to exercise and observer load sharing of traffic into LISP xTR 112, you will need to initiate traffic flows from different sources and destinations. On LISP Site 2 host R117, issue “source-pings” from multiple addresses, such as “ping 192.168.1.1 source 192.168.7.1” and “ping 192.168.1.2 source 192.168.7.3” and observe the results. You can verify how LISP xTR R116 is sending traffic by observing the output of the “show adjacency lisp0 detail” command, and/or how LISP xTR R112 is receiving traffic is to observe the RLOC interface counters. For example, send 500 pings from 192.168.7.1 to 192.168.1.1.

R112-xTR#clear counters Clear "show interface" counters on all interfaces [confirm] R112-xTR# R116-xTR#clear counters Clear "show interface" counters on all interfaces [confirm] R116-xTR# R117-Host7#ping 192.168.1.1 so 192.168.7.1 rep 500 Type escape sequence to abort. Sending 500, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds: Packet sent with a source address of 192.168.7.1

34

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ---<skip>--- !!!!!!!!!! Success rate is 100 percent (500/500), round-trip min/avg/max = 1/3/8 ms R117-Host7# R116-xTR#show adjacency lisp0 detail Protocol Interface Address IP LISP0 10.0.1.2(5) 0 packets, 0 bytes epoch 0 sourced in sev-epoch 0 Encap length 36 450000000000400000115CEA0A000902 0A000102000010F500000000C0CB873B 00000001 LISP Next chain element: IP adj out of Ethernet0/1, addr 10.0.9.1 IP LISP0 10.0.2.2(5) 500 packets, 68000 bytes epoch 0 sourced in sev-epoch 0 Encap length 36 450000000000400000115BEA0A000902 0A000202000010F500000000C0CB873B 00000001 LISP Next chain element: Protocol Interface Address IP adj out of Ethernet0/1, addr 10.0.9.1 R116-xTR# R112-xTR#sh interface eth1/1 | in pack 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 9000 bits/sec, 9 packets/sec 0 packets input, 0 bytes, 0 no buffer 0 input packets with dribble condition detected 501 packets output, 75060 bytes, 0 underruns R112-xTR#sh interface eth1/2 | in pack 5 minute input rate 9000 bits/sec, 9 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 501 packets input, 75154 bytes, 0 no buffer 0 input packets with dribble condition detected 2 packets output, 214 bytes, 0 underruns R112-xTR#

• Now repeat this, but send 500 pings from 192.168.7.3 to 192.168.1.2 (as an example). R112-xTR#clear counters Clear "show interface" counters on all interfaces [confirm] R112-xTR# R116-xTR#clear counters Clear "show interface" counters on all interfaces [confirm] R116-xTR# R117-Host7#ping 192.168.1.2 so 192.168.7.3 rep 500 Type escape sequence to abort. Sending 500, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds: Packet sent with a source address of 192.168.7.3 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ---<skip>--- !!!!!!!!!! Success rate is 100 percent (500/500), round-trip min/avg/max = 1/4/23 ms R117-Host7# R116-xTR#show adjacency lisp0 detail Protocol Interface Address IP LISP0 10.0.1.2(5)

35

500 packets, 68000 bytes epoch 0 sourced in sev-epoch 0 Encap length 36 450000000000400000115CEA0A000902 0A000102000010F500000000C0CB873B 00000001 LISP Next chain element: IP adj out of Ethernet0/1, addr 10.0.9.1 IP LISP0 10.0.2.2(5) 0 packets, 0 bytes epoch 0 sourced in sev-epoch 0 Encap length 36 450000000000400000115BEA0A000902 0A000202000010F500000000C0CB873B 00000001 LISP Next chain element: Protocol Interface Address IP adj out of Ethernet0/1, addr 10.0.9.1 R116-xTR# R112-xTR#sh int eth1/1 | in pack 5 minute input rate 6000 bits/sec, 6 packets/sec 5 minute output rate 9000 bits/sec, 9 packets/sec 500 packets input, 75000 bytes, 0 no buffer 0 input packets with dribble condition detected 501 packets output, 75060 bytes, 0 underruns R112-xTR#sh int eth1/2 | in pack 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 2 packets input, 152 bytes, 0 no buffer 0 input packets with dribble condition detected 4 packets output, 318 bytes, 0 underruns R112-xTR#

• Notice that the LISP xTR R116 has encapsulated packets to both RLOCs on the LISP Site 1

xTR R2, satisfying the 50%/50% ingress traffic engineering policy set by LISP xTR R112.

Note: The ability to achieve accurate load sharing is dependent upon statistically relevant five-tuple hash distributions from all flows. Depending upon this distribution, hashing may or may not be an exactly meet the desired percentages as specified by LISP weights. Given a sufficiently rich distribution, it will be very close, however.

Extra Credit: Explore policy update mechanics • If you would like to observer the process by which an xTR site “updates” its remote

correspondents about a policy change, perform the following tasks. o On xTR R116, enable LISP debugging o On xTR R112, modify the locator-set policy by adjusting one of the locator load shares o Observe the messaging via the LISP debug output on xTR R116, and the propagation of

this policy change R116-xTR#sh ip lisp map-cache LISP IPv4 Mapping Cache for EID-table default (IID 0), 2 entries 0.0.0.0/0, uptime: 01:20:14, expires: never, via static send map-request Negative cache entry, action: send-map-request 192.168.1.0/24, uptime: 00:03:02, expires: 23:57:57, via map-reply, complete Locator Uptime State Pri/Wgt 10.0.1.2 00:01:02 up 1/1 10.0.2.2 00:01:02 up 1/1 R116-xTR# R116-xTR#deb lisp control-plane all All LISP control debugging is on

36

R112-xTR(config)#router lisp R112-xTR(config-router-lisp)#locator-set SITE1 R112-xTR(config-router-lisp-locator-set)#10.0.1.2 priority 1 weight 4 R112-xTR(config-router-lisp-locator-set)# R116-xTR# *Apr 11 05:46:51.535: LISP: Processing received Map-Request message from 10.0.2.2 to

10.0.9.2 *Apr 11 05:46:51.535: LISP: Received map request for IID 0 192.168.7.0/24, source_eid IID

0 192.168.1.0, ITR-RLOCs: 10.0.2.2, records 1, nonce 0xE5539C42-0x78DBF4E6, probe, SMR

*Apr 11 05:46:51.535: LISP-0: AF IID 0 IPv4, Scheduling SMR trigger Map-Request for 192.168.1.0/32 from 192.168.7.0.

*Apr 11 05:46:51.535: LISP: Processing map request record for EID prefix IID 0 192.168.7.0/24

*Apr 11 05:46:51.535: LISP-0: Sending map-reply from 10.0.9.2 to 10.0.2.2. *Apr 11 05:46:51.589: LISP-0: IID 0 Request processing of SMR map requests to IPv4. *Apr 11 05:46:51.589: LISP: Executing work item Net_tx:_0_v4_Map-Request_send[normal] *Apr 11 05:46:51.589: LISP: Send map request type SMR *Apr 11 05:46:51.589: LISP: Send map request for EID prefix IID 0 192.168.1.0/32 *Apr 11 05:46:51.589: LISP-0: AF IID 0 IPv4, Send SMR triggered map request for

192.168.1.0/32 (1) from 192.168.7.0. *Apr 11 05:46:51.589: LISP-0: AF IPv4, Sending map-request from 10.0.9.2 to 192.168.1.0

for EID 192.168.1.0/32, ITR-RLOCs 1, nonce 0x40783E0F-0x3D260D74 (encap src 10.0.9.2, dst 10.0.100.2).

*Apr 11 05:46:51.598: LISP: Processing received Map-Reply message from 10.0.2.2 to 10.0.9.2

*Apr 11 05:46:51.598: LISP: Received map reply nonce 0x40783E0F-0x3D260D74, records 1 *Apr 11 05:46:51.598: LISP: Processing Map-Reply mapping record for IID 0 192.168.1.0/24,

ttl 1440, action none, authoritative, 2 locators 10.0.1.2 pri/wei=1/4 LpR 10.0.2.2 pri/wei=1/1 LpR *Apr 11 05:46:51.598: LISP-0: Map Request IID 0 prefix 192.168.1.0/32 SMR[LL], Received

reply with rtt 1ms. *Apr 11 05:46:51.598: LISP: Processing mapping information for EID prefix IID 0

192.168.1.0/24 *Apr 11 05:46:51.598: LISP-0: Remote EID IID 0 prefix 192.168.1.0/24 RLOC 10.0.1.2

pri/wei=1/4, Add/update locator flags LpR (sources: <map-rep>, state: complete, rlocs: 2).

R116-xTR# *Apr 11 05:46:51.598: LISP-0: Remote EID IID 0 prefix 192.168.1.0/24 RLOC 10.0.1.2

pri/wei=1/4, Updated locator (sources: <map-rep>, state: complete, rlocs: 2). *Apr 11 05:46:51.598: LISP-0: Remote EID IID 0 prefix 192.168.1.0/24 RLOC 10.0.2.2

pri/wei=1/1, Add/update locator flags LpR (sources: <map-rep>, state: complete, rlocs: 2).

*Apr 11 05:46:51.598: LISP-0: Remote EID IID 0 prefix 192.168.1.0/24 RLOC 10.0.2.2 pri/wei=1/1, No change in pri/wei for locator (sources: <map-rep>, state: complete, rlocs: 2).

R116-xTR# R116-xTR#sh ip lisp map-cache LISP IPv4 Mapping Cache for EID-table default (IID 0), 2 entries 0.0.0.0/0, uptime: 00:20:14, expires: never, via static send map-request Negative cache entry, action: send-map-request 192.168.1.0/24, uptime: 00:01:02, expires: 23:59:57, via map-reply, complete Locator Uptime State Pri/Wgt 10.0.1.2 00:01:02 up 1/4 10.0.2.2 00:01:02 up 1/1 R116-xTR#


37

Lab Exercise 7: Deploying LISP Multihoming with IPv4 and IPv6 Locators

Exercise Description In this seventh and final exercise, you will add an IPv6 RLOC interface to the LISP Site1 router (xTR). This exercise simulates the real-world scenario where an Enterprise site decides to add IPv6 WAN connectivity. You will also explore the implications of mixed address family locators, and see how this affects the way that LISP and non-LISP remote sites reach LISP Site1.

Exercise Objective In Exercise 7, the goal is to understand mixed address family implications for both LISP and non-LISP traffic when a LISP site has both IPv4 and IPv6 RLOCs.

Lab Exercise Steps Step 1 Configure LISP Site 1 (R112) for a second IPv4 RLOC. • Ensure that both IPv4 WAN interfaces are “up” (Eth1/1 and Eth1/2) on R112, and that default

routing is set for both interfaces. (This should be the pre-configured state for this Lab. This step simply confirms that current state.)

R112-xTR#show ipv6 interface brief eth1/3 Ethernet1/3 [up/up] FE80::A8BB:CCFF:FE00:7031 2001:DB8:2:3::2 R112-xTR#

38

• Add the IPv6 default route for interface Eth1/3, which will be added to the LISP locator-set. A default route needs to be added for this interface.

R112-xTR(config)#ipv6 route ::/0 2001:db8:2:3::1 R112-xTR(config)#

• Add the IPv6 interface to the LISP locator-set, and give it a priority of 1 and a weight of 1. The

EID prefixes for which this site is authoritative are now associated with two IPv4 RLOCs (10.0.1.2, and 10.0.2.2) and one IPv6 RLOC (2001:db8:2:3::2).

R112-xTR(config)#router lisp R112-xTR(config-router-lisp)#locator-set SITE1 R112-xTR(config-router-lisp-locator-set)# 2001:db8:2:3::2 priority 1 weight 1 R112-xTR(config-router-lisp-locator-set)#^Z R112-xTR#

• It could now be possible to remove the “ipv6 use-petr” command from the configuration.

However, operational considerations which may result in this command being retained o If this command is removed, LISP xTR R112 will now send IPv6 EID-sourced

packets destined to non-LISP IPv6 sites “natively” (i.e. without LISP encapsulation). Return traffic will still be via the PITR (see below). However, if this command is removed and the IPv6 link fails, the LISP site will no longer have access to non-LISP IPv6 destinations since it will only have IPv4 uplinks and no path the PETR.

o If this command is retained, LISP xTR R112 will continue sending IPv6 EID-sourced packets destined to non-LISP IPv6 sites via the PETR (and return traffic will still be via the PITR) (see below). Also, if this command is retained and the IPv6 link fails, the LISP site will still have access to non-LISP IPv6 destinations via the IPv4 uplinks and the PETR.

For this exercise, let’s leave the “ipv6 use-petr” command configured. Step 2 Verify that LISP Site 1 is now using this new information in its database mapping: • Use the “show ip lisp database” command to verify the LISP database on R112. Notice

that the new information matches the configured database-mapping commands. R112-xTR#sh ip lisp database LISP ETR IPv4 Mapping Database for EID-table default (IID 0), LSBs: 0x7, 1 entries 192.168.1.0/24, locator-set SITE1 Locator Pri/Wgt Source State 10.0.1.2 1/1 cfg-addr site-self, reachable 10.0.2.2 1/1 cfg-addr site-self, reachable 2001:DB8:2:3::2 1/1 cfg-addr site-self, reachable R112-xTR#sh ipv6 lisp database LISP ETR IPv6 Mapping Database for EID-table default (IID 0), LSBs: 0x7, 1 entries 2001:DB8:A::/48, locator-set SITE1 Locator Pri/Wgt Source State 10.0.1.2 1/1 cfg-addr site-self, reachable 10.0.2.2 1/1 cfg-addr site-self, reachable 2001:DB8:2:3::2 1/1 cfg-addr site-self, reachable R112-xTR#

Step 3 Test the new IPv6 RLOC functionality. • Only other devices with IPv6 RLOCs can LISP-encapsulated traffic to the IPv6 RLOC of

LISP xTR R112. In this topology, only the PITR (R115) has this capability. But this just means to non-LISP traffic destined for LISP Site 1 EIDs (both IPv4 and IPv6 by the way!) can be encapsulated from the PITR to LISP xTR R112 using all three RLOCs.

• On the LISP xTR R112, source-ping the non-LISP IPv4 destination 10.200.1.1 using the

LISP EID 192.168.1.254 and observe the results.

39

R112-xTR#ping 10.200.1.1 so 192.168.1.254 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.200.1.1, timeout is 2 seconds: Packet sent with a source address of 192.168.1.254 ..!!! Success rate is 60 percent (3/5), round-trip min/avg/max = 1/1/1 ms R112-xTR#

• The return traffic from this ping must be handled buy the PITR (R115). Observe the map-

cache entry now installed on R115. Notice that the PITR is able to use all three RLOCs of LISP xTR R112 and can thus encapsulate traffic (on a per-flow basis) 33/33/33% to R112.

R115-PxTR#sh ip lisp map-cache LISP IPv4 Mapping Cache for EID-table default (IID 0), 2 entries 192.168.0.0/16, uptime: 08:30:37, expires: never, via route-import, send-map-request Negative cache entry, action: send-map-request 192.168.1.0/24, uptime: 00:00:46, expires: 23:59:14, via map-reply, complete Locator Uptime State Pri/Wgt 10.0.1.2 00:00:46 up 1/1 10.0.2.2 00:00:46 up 1/1 2001:DB8:2:3::2 00:00:46 up 1/1 R115-PxTR#

• This can be further observed in detail by reviewing the CEF structure on PITR R115. You

can see from this output how the 15 hash buckets (o through 14) have been distributed in order to achieve the 33/33/33% load sharing.

R115-PxTR#sh ip lisp for eid remo 192.168.1.1 Prefix Fwd action Locator status bits 192.168.1.0/24 encap 0x00000007 packets/bytes 3/300 path list B448D6EC, flags 0x49, 4 locks, per-destination ifnums: LISP0(10): 10.0.1.2, 10.0.2.2, 2001:DB8:2:3::2 3 paths path B448C048, path list B448D6EC, share 1/1, type attached nexthop, for IPv4 nexthop 10.0.1.2 LISP0, adjacency IP midchain out of LISP0, addr 10.0.1.2 B4052D50 path B448BDA8, path list B448D6EC, share 1/1, type attached nexthop, for IPv4 nexthop 10.0.2.2 LISP0, adjacency IP midchain out of LISP0, addr 10.0.2.2 B4052C20 path B448BD38, path list B448D6EC, share 1/1, type attached nexthop, for IPv4 nexthop 2001:DB8:2:3::2 LISP0, adjacency IP midchain out of LISP0, addr

2001:DB8:2:3::2 B4516608 1 output chain chain[0]: loadinfo B1B16A28, per-session, 3 choices, flags 0003, 5 locks flags: Per-session, for-rx-IPv4 Prefix Fwd action Locator status bits 15 hash buckets < 0 > IP midchain out of LISP0, addr 10.0.1.2 B4052D50 IP adj out of Ethernet0/0,

addr 10.0.101.1 B28CC138 < 1 > IP midchain out of LISP0, addr 10.0.2.2 B4052C20 IP adj out of Ethernet0/0,

addr 10.0.101.1 B28CC138 < 2 > IP midchain out of LISP0, addr 2001:DB8:2:3::2 B4516608 IPV6 adj out of

Ethernet0/0, addr 2001:DB8:3:5::1 B28CC008 < 3 > IP midchain out of LISP0, addr 10.0.1.2 B4052D50 IP adj out of Ethernet0/0,







addr 10.0.101.1 B28CC138

40

<10 > IP midchain out of LISP0, addr 10.0.2.2 B4052C20 IP adj out of Ethernet0/0, addr 10.0.101.1 B28CC138

Prefix Fwd action Locator status bits <11 > IP midchain out of LISP0, addr 2001:DB8:2:3::2 B4516608 IPV6 adj out of

Ethernet0/0, addr 2001:DB8:3:5::1 B28CC008 <12 > IP midchain out of LISP0, addr 10.0.1.2 B4052D50 IP adj out of Ethernet0/0,

addr 10.0.101.1 B28CC138 <13 > IP midchain out of LISP0, addr 10.0.2.2 B4052C20 IP adj out of Ethernet0/0,

addr 10.0.101.1 B28CC138 <14 > IP midchain out of LISP0, addr 2001:DB8:2:3::2 B4516608 IPV6 adj out of

Ethernet0/0, addr 2001:DB8:3:5::1 B28CC008 Subblocks: None R115-PxTR#

• Notice that the “locator status bits” shows 0x00000007 (representing the Locator-Status-Bits

(LSB) binary value of 0000 00111), indicating that the remote site (R112) has three locators, all are considered “up” and available for LISP encapsulated packets to reach 192.168.1.0/24.

• On the LISP xTR R112, now source-ping the non-LISP IPv6 destination 2001:db8:c5c0::1

using the LISP EID 2001:db8:a:1::254 and observe the results. R112-xTR#ping 2001:db8:c5c0::1 so 2001:db8:a:1::254 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2001:DB8:C5C0::1, timeout is 2 seconds: Packet sent with a source address of 2001:DB8:A:1::254 ..!!! Success rate is 60 percent (3/5), round-trip min/avg/max = 1/1/1 ms R112-xTR#

• On the LISP xTR R112, review the IPv6 LISP map-cache.

R112-xTR#sh ipv6 lisp map-cache LISP IPv6 Mapping Cache for EID-table default (IID 0), 3 entries ---<skip>--- 2001:DB8:8000::/33, uptime: 00:00:08, expires: 00:14:52, via map-reply, forward-native Encapsulating to proxy ETR R112-xTR#

• Note that traffic destined to non-LISP IPv6 space continues to use the PETR on egress. IPv6

return traffic from this ping must be handled buy the PITR (R115). • Observe the map-cache entry now installed on R115. Notice that the PITR is able to use all

three RLOCs of LISP xTR R112 and can thus encapsulate traffic (on a per-flow basis) 33/33/33% to R112.

R115-PxTR#sh ipv6 lisp map-cache LISP IPv6 Mapping Cache for EID-table default (IID 0), 3 entries ---<skip>--- 2001:DB8:A::/48, uptime: 00:00:34, expires: 23:59:27, via map-reply, complete Locator Uptime State Pri/Wgt 10.0.1.2 00:00:34 up 1/1 10.0.2.2 00:00:34 up 1/1 2001:DB8:2:3::2 00:00:34 up 1/1 2001:DB8:B::/48, uptime: 00:09:43, expires: 23:57:34, via map-reply, complete Locator Uptime State Pri/Wgt 10.0.9.2 00:09:43 up 1/1 R115-PxTR#R112-xTR#

41

• On the LISP PxTR R115, review the details of the IPv6 EID LISP forwarding to R112. This looks identical to the IPv4 EID LISP forwarding.

R115-PxTR#sh ipv6 lisp for eid rem 2001:db8:a:1::1 Prefix Fwd action Locator status bits 2001:DB8:A::/48 encap 0x00000007 packets/bytes 3/300 path list B448D5AC, flags 0x49, 4 locks, per-destination ifnums: LISP0(10): 10.0.1.2, 10.0.2.2, 2001:DB8:2:3::2 3 paths path B448BE88, path list B448D5AC, share 1/1, type attached nexthop, for IPv6 nexthop 10.0.1.2 LISP0, adjacency IPV6 midchain out of LISP0, addr 10.0.1.2 B45164D8 path B448BA28, path list B448D5AC, share 1/1, type attached nexthop, for IPv6 nexthop 10.0.2.2 LISP0, adjacency IPV6 midchain out of LISP0, addr 10.0.2.2 B45163A8 path B448B9B8, path list B448D5AC, share 1/1, type attached nexthop, for IPv6 nexthop 2001:DB8:2:3::2 LISP0, adjacency IPV6 midchain out of LISP0, addr

2001:DB8:2:3::2 B4516278 1 output chain chain[0]: loadinfo B1B16974, per-session, 3 choices, flags 0005, 5 locks flags: Per-session, for-rx-IPv6 Prefix Fwd action Locator status bits 15 hash buckets < 0 > IPV6 midchain out of LISP0, addr 10.0.1.2 B45164D8 IP adj out of Ethernet0/0,

addr 10.0.101.1 B28CC138 < 1 > IPV6 midchain out of LISP0, addr 10.0.2.2 B45163A8 IP adj out of Ethernet0/0,

addr 10.0.101.1 B28CC138 < 2 > IPV6 midchain out of LISP0, addr 2001:DB8:2:3::2 B4516278 IPV6 adj out of

Ethernet0/0, addr 2001:DB8:3:5::1 B28CC008 < 3 > IPV6 midchain out of LISP0, addr 10.0.1.2 B45164D8 IP adj out of Ethernet0/0,







addr 10.0.101.1 B28CC138 <10 > IPV6 midchain out of LISP0, addr 10.0.2.2 B45163A8 IP adj out of Ethernet0/0,

addr 10.0.101.1 B28CC138 Prefix Fwd action Locator status bits <11 > IPV6 midchain out of LISP0, addr 2001:DB8:2:3::2 B4516278 IPV6 adj out of

Ethernet0/0, addr 2001:DB8:3:5::1 B28CC008 <12 > IPV6 midchain out of LISP0, addr 10.0.1.2 B45164D8 IP adj out of Ethernet0/0,

addr 10.0.101.1 B28CC138 <13 > IPV6 midchain out of LISP0, addr 10.0.2.2 B45163A8 IP adj out of Ethernet0/0,

addr 10.0.101.1 B28CC138 <14 > IPV6 midchain out of LISP0, addr 2001:DB8:2:3::2 B4516278 IPV6 adj out of

Ethernet0/0, addr 2001:DB8:3:5::1 B28CC008 Subblocks: None R115-PxTR#

• On the LISP xTR R112, now source-ping the LISP IPv6 EID destination 2001:db8:b:1::254

using the LISP EID 2001:db8:a:1::254 and observe the results. R112-xTR#ping 2001:db8:b:1::254 so 2001:db8:a:1::254 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2001:DB8:B:1::254, timeout is 2 seconds: Packet sent with a source address of 2001:DB8:A:1::254 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms R112-xTR#

42

• On the LISP xTR R112, review the IPv6 LISP map-cache. Note that the IPv6 EID space is encapsulated in IPv4 to match the only RLOC available on LISP Site 2 xTR R116.

R112-xTR#sh ipv6 lisp for eid remo 2001:db8:b:1::1 Prefix Fwd action Locator status bits 2001:DB8:B::/48 encap 0x00000001 packets/bytes 1004/67072 path list B3499ADC, flags 0x49, 3 locks, per-destination ifnums: LISP0(15): 10.0.9.2 1 path path B25CB5E0, path list B3499ADC, share 1/1, type attached nexthop, for IPv6 nexthop 10.0.9.2 LISP0, adjacency IPV6 midchain out of LISP0, addr 10.0.9.2 B4741398 1 output chain chain[0]: IPV6 midchain out of LISP0, addr 10.0.9.2 B4741398 IP adj out of

Ethernet1/1, addr 10.0.1.1 B1E6A0B0 R112-xTR#

• The more interesting result, perhaps, is to review the IPv6 LISP map-cache entry on LISP

Site 2 xTR R116. Since this xTR only has IPv4 RLOC connectivity, it can only LISP-encapsulate packets to R112 using IPv4. Let’s look at the map-cache entry on R116.

R116-xTR#sh ip lisp map-cache LISP IPv4 Mapping Cache for EID-table default (IID 0), 2 entries 0.0.0.0/0, uptime: 04:01:49, expires: never, via static send map-request Negative cache entry, action: send-map-request 192.168.1.0/24, uptime: 03:42:36, expires: 23:43:15, via map-reply, complete Locator Uptime State Pri/Wgt 10.0.1.2 03:42:36 up 1/1 10.0.2.2 03:42:36 up 1/1 2001:DB8:2:3::2 00:17:23 no-route 1/1 R116-xTR# R116-xTR#sh ipv6 lisp map-cache LISP IPv6 Mapping Cache for EID-table default (IID 0), 2 entries ::/0, uptime: 05:18:28, expires: never, via static send map-request Negative cache entry, action: send-map-request 2001:DB8:A::/48, uptime: 01:27:35, expires: 23:59:46, via map-reply, complete Locator Uptime State Pri/Wgt 10.0.1.2 01:27:35 up 1/1 10.0.2.2 01:27:35 up 1/1 2001:DB8:2:3::2 01:27:35 no-route 1/1 R116-xTR#

• Notice in this case that the IPv6 locator for the IPv4 and IPv6 EIDs is marked “no-route.” In

this case, R116 will not use the IPv6 RLOC for encapsulation (it cannot). • On the LISP xTR R116, review the details of the IPv6 EID LISP forwarding to R112. Note

that only the two IPv4 RLOCs are used for encapsulation (implying a 50/50% load share). R116-xTR#sh ipv6 lisp forwarding eid remote 2001:db8:a:1::1 Prefix Fwd action Locator status bits 2001:DB8:A::/48 encap 0x00000007 packets/bytes 1008/100800 path list B36EB02C, flags 0x49, 3 locks, per-destination ifnums: LISP0(11): 10.0.1.2, 10.0.2.2 2 paths path B42FD298, path list B36EB02C, share 0/1, type attached nexthop, for IPv6 nexthop 10.0.1.2 LISP0, adjacency IPV6 midchain out of LISP0, addr 10.0.1.2 B458F0E8 path B42FCF88, path list B36EB02C, share 1/1, type attached nexthop, for IPv6 nexthop 10.0.2.2 LISP0, adjacency IPV6 midchain out of LISP0, addr 10.0.2.2 B458EFB8 1 output chain chain[0]: loadinfo B1B7BD24, per-session, 2 choices, flags 0085, 5 locks flags: Per-session, for-rx-IPv6, 2buckets 2 hash buckets

43

< 0 > IPV6 midchain out of LISP0, addr 10.0.1.2 B458F0E8 IP adj out of Ethernet0/1, addr 10.0.9.1 B2931108

< 1 > IPV6 midchain out of LISP0, addr 10.0.2.2 B458EFB8 IP adj out of Ethernet0/1, addr 10.0.9.1 B2931108

Prefix Fwd action Locator status bits Subblocks: None R116-xTR#

End of Lab: Congratulations! You have successfully completed the lab. Please let your proctor know you finished and provide any feedback to help improve the lab experience. End of Exercise: You have successfully completed this exercise. Proceed to next section.

44

Appendix A: Additional Resources You can find other useful information related to the topics covered in this lab at the following URLs. Cisco Information:

• Cisco LISP Download Site (EXTERNAL) You can find software downloads, configurations, command reference guides, and more. This is the site that “customers” see. http://lisp.cisco.com (IPv4 and IPv6 accessible)

• Cisco LISP Marketing Page (EXTERNAL) Cisco Marketing maintains this page. This site is available to customers. http://www.cisco.com/go/lisp

Other LISP Information:

• LISP Beta Network (EXTERNAL) You can find operational information on the LISP Beta Network, and general LISP protocol information. This site is available to customers. http://www.lisp4.net/ http://www.lisp6.net

45

Appendix B: Final Configurations The final configurations for all routers used in this lab follow. RTR113 (core) ! hostname R113-Core ! no ip domain lookup ip cef ipv6 unicast-routing ipv6 cef ! interface Loopback0 no ip address ipv6 address 2001:DB8:C5C0::1/48 ! interface Loopback1 ip address 10.200.1.1 255.255.255.0 ! interface Ethernet0/0 description Connection to MSMR ip address 10.0.100.1 255.255.255.252 ipv6 address 2001:DB8:3:4::1/64 ! interface Ethernet0/1 description Connection to PxTR ip address 10.0.101.1 255.255.255.252 ipv6 address 2001:DB8:3:5::1/64 ! interface Ethernet0/2 description Connection to LISP Site 2 (RTR 116) ip address 10.0.9.1 255.255.255.252 ! interface Ethernet1/1 description Connection to LISP Site 1 (RTR 112) ip address 10.0.1.1 255.255.255.252 ! interface Ethernet1/2 description Connection to LISP Site 1 (RTR 112) ip address 10.0.2.1 255.255.255.252 ! interface Ethernet1/3 description Connection to LISP Site 1 (RTR 112) no ip address ipv6 address 2001:DB8:2:3::1/64 ! router bgp 3 bgp asnotation dot bgp log-neighbor-changes neighbor 10.0.101.2 remote-as 5 neighbor 2001:DB8:3:5::2 remote-as 5 ! address-family ipv4 neighbor 10.0.101.2 activate neighbor 2001:DB8:3:5::2 activate exit-address-family ! address-family ipv6 neighbor 2001:DB8:3:5::2 activate exit-address-family ! ip bgp-community new-format ! line con 0 exec-timeout 0 0 privilege level 15 logging synchronous line aux 0 line vty 0 4 exec-timeout 0 0

46

privilege level 15 password cisco login transport input all !

RTR114 (MSMR) ! hostname R114-MSMR ! no ip domain lookup ip cef ipv6 unicast-routing ipv6 cef ! interface LISP0 ! interface Ethernet0/0 ip address 10.0.100.2 255.255.255.252 ipv6 address 2001:DB8:3:4::2/64 ! router lisp site site1 description LISP Site 1 - GOLD Lab authentication-key SITE1KEY eid-prefix 192.168.1.0/24 eid-prefix 2001:DB8:A::/48 exit ! site site2 description Site 2 - GOLD Lab authentication-key SITE2KEY eid-prefix 192.168.7.0/24 eid-prefix 2001:DB8:B::/48 exit ! ipv4 map-server ipv4 map-resolver ipv6 map-server ipv6 map-resolver exit ! ip route 0.0.0.0 0.0.0.0 10.0.100.1 ! ipv6 route ::/0 2001:DB8:3:4::1 ! line con 0 exec-timeout 0 0 privilege level 15 logging synchronous line aux 0 line vty 0 4 exec-timeout 0 0 privilege level 15 password cisco login transport input all !

RTR115 (PxTR) ! hostname R115-PxTR ! no ip domain lookup ip cef ipv6 unicast-routing ipv6 cef ! interface LISP0 ! interface Ethernet0/0

47

ip address 10.0.101.2 255.255.255.252 ipv6 address 2001:DB8:3:5::2/64 ! router lisp eid-table default instance-id 0 ipv4 route-import map-cache static route-map EID-space ipv6 route-import map-cache static route-map EID-space exit ! loc-reach-algorithm rloc-probing ipv4 map-request-source 10.0.101.2 no ipv4 map-cache-persistent ipv4 map-cache-limit 100000 ipv4 proxy-etr ipv4 proxy-itr 10.0.101.2 2001:DB8:3:5::2 ipv4 itr map-resolver 10.0.100.2 ipv6 map-request-source 2001:DB8:3:5::2 no ipv6 map-cache-persistent ipv6 map-cache-limit 100000 ipv6 proxy-etr ipv6 proxy-itr 2001:DB8:3:5::2 10.0.101.2 ipv6 itr map-resolver 10.0.100.2 exit ! router bgp 5 bgp asnotation dot bgp log-neighbor-changes neighbor 10.0.101.1 remote-as 3 neighbor 2001:DB8:3:5::1 remote-as 3 ! address-family ipv4 redistribute static route-map pop-EID neighbor 10.0.101.1 activate no neighbor 2001:DB8:3:5::1 activate exit-address-family ! address-family ipv6 redistribute static route-map pop-EID neighbor 2001:DB8:3:5::1 activate exit-address-family ! ip bgp-community new-format ! ip route 0.0.0.0 0.0.0.0 10.0.101.1 ip route 192.168.0.0 255.255.0.0 Null0 tag 111 ! ipv6 route 2001:DB8:A::/47 Null0 tag 111 ipv6 route ::/0 2001:DB8:3:5::1 ! route-map EID-space permit 10 match tag 111 ! route-map pop-EID permit 10 match tag 111 set origin igp set community 111:5 ! line con 0 exec-timeout 0 0 privilege level 15 logging synchronous line aux 0 line vty 0 4 exec-timeout 0 0 privilege level 15 password cisco login transport input all !

48

RTR112 (LISP Site 1 xTR) ! hostname R112-xTR ! no ip domain lookup ip cef ipv6 unicast-routing ipv6 cef ! interface Loopback0 ip address 192.168.1.254 255.255.255.255 ipv6 address 2001:DB8:A:1::254/128 ! interface LISP0 ! interface Ethernet0/0 ip address 172.16.1.2 255.255.255.0 ip ospf 1 area 0 ipv6 address 2001:DB8:A:2::2/64 ipv6 ospf 6 area 0 ! interface Ethernet1/1 ip address 10.0.1.2 255.255.255.252 ! interface Ethernet1/2 ip address 10.0.2.2 255.255.255.252 ! interface Ethernet1/3 no ip address ipv6 address 2001:DB8:2:3::2/64 ! router lisp locator-set SITE1 10.0.1.2 priority 1 weight 1 10.0.2.2 priority 1 weight 1 2001:DB8:2:3::2 priority 1 weight 1 exit ! eid-table default instance-id 0 database-mapping 192.168.1.0/24 locator-set SITE1 database-mapping 2001:DB8:A::/48 locator-set SITE1 exit ! loc-reach-algorithm rloc-probing ipv4 itr map-resolver 10.0.100.2 ipv4 itr ipv4 etr map-server 10.0.100.2 key SITE1KEY ipv4 etr ipv6 use-petr 10.0.101.2 ipv6 itr map-resolver 10.0.100.2 ipv6 itr ipv6 etr map-server 10.0.100.2 key SITE1KEY ipv6 etr exit ! router ospf 1 default-information originate ! ip route 0.0.0.0 0.0.0.0 10.0.1.1 ip route 0.0.0.0 0.0.0.0 10.0.2.1 ! ipv6 route ::/0 2001:DB8:2:3::1 ipv6 router ospf 6 default-information originate always ! alias exec shbr show ip interface brief | exclude admin|un|Int alias exec sh0 sh ip int br | ex un|do ! line con 0 exec-timeout 0 0 privilege level 15 logging synchronous line aux 0

49

line vty 0 4 exec-timeout 0 0 privilege level 15 password cisco login transport input all !

RTR111 (LISP Site 1 Host) ! hostname R111-Host1 ! no ip domain lookup ip cef ipv6 unicast-routing ipv6 cef ! interface Loopback1 ip address 192.168.1.1 255.255.255.255 ipv6 address 2001:DB8:A:1::1/128 ipv6 ospf 6 area 0 ! interface Loopback2 ip address 192.168.1.2 255.255.255.255 ipv6 address 2001:DB8:A:1::2/128 ipv6 ospf 6 area 0 ! interface Loopback3 ip address 192.168.1.3 255.255.255.255 ipv6 address 2001:DB8:A:1::3/128 ipv6 ospf 6 area 0 ! interface Loopback4 ip address 192.168.1.4 255.255.255.255 ipv6 address 2001:DB8:A:1::4/128 ipv6 ospf 6 area 0 ! interface Ethernet0/0 ip address 172.16.1.1 255.255.255.0 ip ospf 1 area 0 ipv6 address 2001:DB8:A:2::1/64 ipv6 ospf 6 area 0 ! router ospf 1 network 192.168.1.0 0.0.0.255 area 0 ! ipv6 router ospf 6 ! line con 0 exec-timeout 0 0 privilege level 15 logging synchronous line aux 0 line vty 0 4 exec-timeout 0 0 privilege level 15 password cisco login transport input all !

RTR116 (LISP Site 2 xTR) ! hostname R116-xTR ! no ip domain lookup ip cef ipv6 unicast-routing ipv6 cef ! interface Loopback0

50

ip address 192.168.7.254 255.255.255.255 ipv6 address 2001:DB8:B:1::254/128 ! interface LISP0 ! interface Ethernet0/0 description Conn to Inside (hosts) ip address 172.16.7.2 255.255.255.0 ip ospf 1 area 0 ipv6 address 2001:DB8:B:2::2/64 ipv6 ospf 6 area 0 ! interface Ethernet0/1 description Conn to CORE (RLOC for LISP) ip address 10.0.9.2 255.255.255.252 ! router lisp locator-set SITE2 10.0.9.2 priority 1 weight 1 exit ! eid-table default instance-id 0 database-mapping 192.168.7.0/24 locator-set SITE2 database-mapping 2001:DB8:B::/48 locator-set SITE2 exit ! loc-reach-algorithm rloc-probing ipv4 itr map-resolver 10.0.100.2 ipv4 itr ipv4 etr map-server 10.0.100.2 key SITE2KEY ipv4 etr ipv6 use-petr 10.0.101.2 ipv6 itr map-resolver 10.0.100.2 ipv6 itr ipv6 etr map-server 10.0.100.2 key SITE2KEY ipv6 etr exit ! router ospf 1 default-information originate always ! ip route 0.0.0.0 0.0.0.0 10.0.9.1 ! ipv6 router ospf 6 router-id 172.16.7.2 default-information originate always ! line con 0 exec-timeout 0 0 privilege level 15 logging synchronous line aux 0 line vty 0 4 exec-timeout 0 0 privilege level 15 password cisco login transport input all !

RTR117 (LISP Site 2 Host) ! hostname R117-Host7 ! no ip domain lookup ip cef ipv6 unicast-routing ipv6 cef ! interface Loopback1 ip address 192.168.7.1 255.255.255.255 ipv6 address 2001:DB8:B:1::1/128

51

ipv6 ospf 6 area 0 ! interface Loopback2 ip address 192.168.7.2 255.255.255.255 ipv6 address 2001:DB8:B:1::2/128 ipv6 ospf 6 area 0 ! interface Loopback3 ip address 192.168.7.3 255.255.255.255 ipv6 address 2001:DB8:B:1::3/128 ipv6 ospf 6 area 0 ! interface Loopback4 ip address 192.168.7.4 255.255.255.255 ipv6 address 2001:DB8:B:1::4/128 ipv6 ospf 6 area 0 ! interface Ethernet0/0 ip address 172.16.7.1 255.255.255.0 ip ospf 1 area 0 ipv6 address 2001:DB8:B:2::1/64 ipv6 ospf 6 area 0 ! router ospf 1 network 192.168.7.0 0.0.0.255 area 0 ! ipv6 router ospf 6 ! line con 0 exec-timeout 0 0 privilege level 15 logging synchronous line aux 0 line vty 0 4 exec-timeout 0 0 privilege level 15 password cisco login transport input all !

lisp lab guide

Documents