Configure and Troubleshoot LISP

Available Languages

Download Options

  • PDF     (36.7 KB)
    View with Adobe Reader on a variety of devices
  • ePub     (88.7 KB)
    View in various apps on iPhone, iPad, Android, Sony Reader, or Windows Phone
  • Mobi (Kindle)     (111.1 KB)
    View on Kindle device or Kindle app on multiple devices
Updated:October 27, 2015
Document ID:200216

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Introduction

Cisco Locator/ID Separation Protocol(LISP) changes current IP address semantics by creating two new namespaces: Endpoint Identifiers (EIDs) that are assigned to end-hosts and Routing Locators (RLOCs) that are assigned to devices (primarily routers) that make up the global routing system.

When router has the full internet routing table it need memory and process utilization and LISP can help in reducing the memory utilzation .

Prerequisites

Cisco recommends that you have basic knowledge of LISP.

Components Used

This document is not restricted to specific software and hardware versions.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Configure

Network Diagram

Following image would be used as a sample topology for rest of the document:

xTR = A LISP router can be ITR or ETR depending on the traffic flow direction. If traffic is going out of the LISP router, it becomes ITR for that flow and the receiving end LISP router becomes ETR for that router.

ITR = Ingress Tunnel Router

ETR = Egress Tunnel Router

Map Resolver (MR) = A Map-Resolver is a LISP infrastructure device to which LISP site ITRs send LISP Map-Request    queries when resolving EID-to-RLOC mappings. R5 is the MR in this article.

Map Server (MS) =  A Map-Server is a LISP infrastructure device to which LISP site ETRs register with their EID prefixes. The Map-Server advertises aggregates for the registered EID prefixes to the LISP mapping system. All LISP sites use the LISP mapping system to resolve EID-to-RLOC mappings. R7 is the MS in this article.

Endpoint Identifier (EID) addresses: EID addresses consist of the IP addresses and prefixes identifying the endpoints. EID reachability across LISP sites is achieved by resolving EID-to-RLOC mappings.

Route Locator (RLOC) addresses: RLOC addresses consist of the IP addresses and prefixes identifying the different routers in the IP network. Reachability within the RLOC space is achieved by traditional routingmethods.

ALT(Alternative Logical Topology): Link connecting Map Resolver and Map Server, passing through  R6, is the ALT in this diagram and is solely used for control plane communication between the two. This link is never used for actual traffic flow between the xTR.

alt-vrf: This Virtual Routing and Forwarding (VRF) is used to configure which VRF instance supporting the IPv4 address-family that Locator/ID Separation Protocol (LISP) should use when sending map requests for an IPv4 endpoint identifier-to-routing locator ( EID-to-RLOC) mapping directly over the alternative logical topology (ALT)

R1 config

!
router lisp
database-mapping 172.16.1.1/32 10.1.12.1 priority 5 weight 100 ------> EID Mapping with RLOC
 ipv4 itr map-resolver 192.168.5.5
 ipv4 itr
ipv4 etr map-server 192.168.7.7 key cisco ---> ETR will send the map-register message to map server for EID
 ipv4 etr
 exit
 !

R4 Config

!
router lisp
database-mapping 172.16.4.4/32 10.1.34.4 priority 5 weight 100 ------> EID Mapping with RLOC
ipv4 itr map-resolver 192.168.5.5
 ipv4 itr
ipv4 etr map-server 192.168.7.7 key cisco ---> ETR will send the map-register message to map server for EID
 ipv4 etr
 exit
 !

R5: Map Resolver Config

Under Map-Resolved, its mandatory to define a vrf as alt-vrf which will be used to form MPBGP peering between the MR and MS and will then be used to share EIDs of remote sites as registered to MS by xTR.

!
vrf definition lisp
 rd 100:1
 !
 address-family ipv4
  route-target export 100:1
  route-target import 100:1
 exit-address-family
!
!
interface Tunnel1
 vrf forwarding lisp
 ip address 10.1.45.4 255.255.255.0
 tunnel source Ethernet0/1
 tunnel destination 10.1.67.7
!
!       
router lisp
 ipv4 map-resolver
ipv4 alt-vrf lisp >>> This command defines "lisp" as the alt-vrf.
 exit
!
router bgp 65000
 !
 address-family ipv4 vrf lisp
  neighbor 10.1.45.5 remote-as 65000
  neighbor 10.1.45.5 activate
 exit-address-family
! 

R7: MAP-Server Config

Similar to MR, alt-vrf is required to be configured on the MS as well.

!
router lisp
 site 1
  authentication-key cisco
  eid-prefix 172.16.4.4/32 accept-more-specifics
  exit
 !
 site 2
  authentication-key cisco
  eid-prefix 172.16.1.1/32 accept-more-specifics
  exit
 !
 ipv4 map-server
 ipv4 alt-vrf lisp            >>>>>>> ALT VRF is lisp
 exit
!
vrf definition lisp
 rd 100:1
 !
 address-family ipv4
  route-target export 100:1
  route-target import 100:1
 exit-address-family
!
!
interface Tunnel1
 vrf forwarding lisp
 ip address 10.1.45.5 255.255.255.0
 tunnel source Ethernet0/0
 tunnel destination 10.1.56.5
!
router bgp 65000
 !
 address-family ipv4 vrf lisp
  redistribute lisp
  neighbor 10.1.45.4 remote-as 65000
  neighbor 10.1.45.4 activate
 exit-address-family
!
end

Verify

In order to trigger LISP communication, one of the following conditions needs to be met:

  1. Default route should be pointed to null 0 on xTRs.
  2. Specific route to the remote xTR's EID shouldn't be present on any of the xTRs.

Below is the order of operation:

  1. Both the ETR should send the map-register message to the map-server for their EIDs and RLOC address.
  2. When a ping from the ITR to ETR is done i.e. from 172.16.1.1 to 172.16.4.4, then ITR 172.16.1.1 will send the map-request message to map-resolver 172.16.5.5 and map-resolver will forward the request to map-server over the ALT topology .
  3. Once MS will receive the request from MR and it will forward the same map-request to remote ETR. 
  4. Once ETR will recieve the map-request it will reply to ITR directly with its RLOC address.
R1_XTR#sh ip route 172.16.4.4 -----> R4's EID
% Subnet not in table

R1_XTR#sh ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
  Known via "static", distance 1, metric 0 (connected), candidate default path
  Routing Descriptor Blocks:
  * directly connected, via Null0
      Route metric is 0, traffic share count is 1

As shown above, route to R4's EID: 17.16.4.4 is not in routing table. Instead a default route pointing towards the null0 was statically configured. With neccessary trigger conditions met, a ping to 17.16.4.4 will now trigger LISP encapsulation.

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

For above ping to work, information about the destination xTR was sent to R1 by R4 through LISP communication:

R1_XTR#sh ip lisp map-cache  
LISP IPv4 Mapping Cache for EID-table default (IID 0), 2 entries

0.0.0.0/0, uptime: 06:10:24, expires: never, via static send map-request
  Negative cache entry, action: send-map-request
172.16.4.4/32, uptime: 05:55:27, expires: 18:04:32, via map-reply, complete
  Locator    Uptime    State      Pri/Wgt
  10.1.34.4  05:55:27  up           1/100

Troubleshoot

  

Below are some debug outputs and packet capture taken to check the LISP packet flow. Following debug command was enabled to capture the information: "debug lisp control-plane all". 

  

Note: Please note the debug command generates considerable amount of data and needs to run in controlled environment.

Debug on the xTR- R1

In below debug messages, R1 is registering its EID with MS and MS is then acknowledging. Similarly, R4 will also be registering its EIDs with MS.

*Oct 16 12:46:09.398: LISP-0: IPv4 Map Server IID 0 192.168.7.7, Sending map-register (src_rloc 10.1.15.1) nonce 0xBEB73F0C-0xFE3EBC4E.
*Oct 16 12:46:09.403: LISP: Processing received Map-Notify message from 192.168.7.7 to 10.1.15.1

Now, a ping is initiated from R1 towards R4's EID, sourced from R1's EID and R1 immediately sends a Map-Request packet to the MR.

R1_XTR#ping 172.16.4.4 source 172.16.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.4.4, timeout is 2 seconds:
Packet sent with a source address of 172.16.1.1

*Oct 16 12:46:23.380: LISP: Send map request type remote EID prefix
*Oct 16 12:46:23.380: LISP: Send map request for EID prefix IID 0 172.16.4.4/32
*Oct 16 12:46:23.380: LISP-0: Remote EID IID 0 prefix 172.16.4.4/32, Send map request (1) (sources: <signal>, state: incomplete, rlocs: 0).
*Oct 16 12:46:23.380: LISP-0: AF IPv4, Sending map-request from 10.1.12.1 to 172.16.4.4 for EID 172.16.4.4/32, ITR-RLOCs 1, nonce 0x99255979-0x30A1BAC1 (encap src 10.1.15.1, dst 192.168.5.5).

MR on receiving the packet contacts MS to identify the xTR registered for this EID and forwards the Map-Request message to R4. R4 in return, sends a Map-Reply back to R1 with its RLOC:

*Oct 16 12:46:23.389: LISP: Processing received Map-Reply message from 10.1.34.4 to 10.1.12.1
*Oct 16 12:46:23.389: LISP: Received map reply nonce 0x99255979-0x30A1BAC1, records 1
*Oct 16 12:46:23.389: LISP: Processing Map-Reply mapping record for IID 0 172.16.4.4/32, ttl 1440, action none, authoritative, 1 locator
 10.1.34.4 pri/wei=1/100 LpR
*Oct 16 12:46:23.389: LISP-0: Map Request IID 0 prefix 172.16.4.4/32 remote EID prefix[LL], Received reply with rtt 9ms.
*Oct 16 12:46:23.389: LISP: Processing mapping information for EID prefix IID 0 172.16.4.4/32

Map-Resolver Packet flow

As shown below, MR first receives a Map-request message from R1 to know the RLOC for the 172.16.4.4. It then checks its BGP lisp vrf table for a match in the learnt EIDs from MS and on finding a match MR forwards the map-request to MS:

LISP_Resolver#show ip bgp vpnv4 vrf lisp
BGP table version is 3, local router ID is 192.168.5.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 100:1 (default for vrf lisp)
*>i 172.16.1.1/32    10.1.45.5                1    100      0 ?
*>i 172.16.4.4/32    10.1.45.5                1    100      0 ?
*Oct 16 12:46:23.384: LISP: Processing received Map-Request message from 10.1.12.1 to 172.16.4.4
*Oct 16 12:46:23.384: LISP: Received map request for IID 0 172.16.4.4/32, source_eid IID 0 172.16.1.1, ITR-RLOCs: 10.1.12.1, records 1, nonce 0x99255979-0x30A1BAC1
*Oct 16 12:46:23.384: LISP-0: AF IID 0 IPv4, Forwarding map request to 172.16.4.4 on the ALT.

Note: Even though log message says the map-request is being forwarded to 172.16.4.4 it is actually sent to the MS as per the next-hop entry in the BGP table.

Map-Server Packet flow

Debugs run on MS shows Map-Register messages coming from both R1 and R4 first to register their respective ETRs:

*Oct 16 12:46:09.398: LISP: Processing Map-Register mapping record for IID 0 172.16.1.1/32, ttl 1440, action none, authoritative, 1 locator
 10.1.12.1 pri/wei=5/100 LpR
*Oct 16 12:46:09.398: LISP-0: MS registration IID 0 prefix 172.16.1.1/32 10.1.15.1 site 2, Updating.
*Oct 16 12:46:41.445: LISP: Processing Map-Register mapping record for IID 0 172.16.4.4/32, ttl 1440, action none, authoritative, 1 locator
 10.1.34.4 pri/wei=1/100 LpR
*Oct 16 12:46:41.445: LISP-0: MS registration IID 0 prefix 172.16.4.4/32 10.1.47.4 site 1, Updating.

Now, both xTRs have successfully registered their EIDs:

R7#show lisp site detail
LISP Site Registration Information
Site name: 1
Allowed configured locators: any
Allowed EID-prefixes:
  EID-prefix: 172.16.4.4/32
    First registered:     05:02:48    Routing table tag:    0
    Origin:               Configuration, accepting more specifics
    Merge active:         No
    Proxy reply:          No
    TTL:                  1d00h
    State:                complete
    Registration errors: 
      Authentication failures:   0
      Allowed locators mismatch: 0
    ETR 10.1.47.4, last registered 00:00:21, no proxy-reply, map-notify
                   TTL 1d00h, no merge, hash-function sha1, nonce 0x56D89121-0xC39C2892
                   state complete, no security-capability
                   xTR-ID 0xF7DE6C93-0x06F8DDA4-0x7D6400B1-0x19EC9669
                   site-ID unspecified
      Locator    Local  State      Pri/Wgt
      10.1.34.4  yes    up           1/100
Site name: 2
Allowed configured locators: any
Allowed EID-prefixes:
 EID-prefix: 172.16.1.1/32
    First registered:     05:02:46
    Routing table tag:    0
    Origin:               Configuration, accepting more specifics
    Merge active:         No
    Proxy reply:          No
    TTL:                  1d00h
    State:                complete
    Registration errors: 
      Authentication failures:   0
      Allowed locators mismatch: 0
    ETR 10.1.15.1, last registered 00:00:50, no proxy-reply, map-notify
                   TTL 1d00h, no merge, hash-function sha1, nonce 0xBEB73F0C-0xFE3EBC4E
                   state complete, no security-capability
                   xTR-ID 0xCF7E1300-0x302FF91A-0x1C2D0499-0x8A105258
                   site-ID unspecified
      Locator    Local  State      Pri/Wgt
      10.1.12.1  yes    up           5/100

When the ping is performed from R1 and MR sends the Map-request message to MS, following logs can be seen on MS:

*Oct 16 12:46:23.388: LISP: Processing received Map-Request message from 10.1.12.1 to 172.16.4.4
*Oct 16 12:46:23.388: LISP: Received map request for IID 0 172.16.4.4/32, source_eid IID 0 172.16.1.1, ITR-RLOCs: 10.1.12.1, records 1, nonce 0x99255979-0x30A1BAC1
*Oct 16 12:46:23.388: LISP-0: MS EID IID 0 prefix 172.16.4.4/32 site 1, Forwarding map request to ETR RLOC 10.1.34.4.

xTR2-R4 Packet flow

Following events happens on R4:

  1. R4 receives a LISP encapsulated message from R7 i.e. MS.
  2. Packet is decapsulated and is found to be the same Map-Request that R1 earlier sent to R5 i.e. MS which was later forwarded to the MS from MR.
  3. R4 then sends a Map-Reply message directly to R1.
*Oct 16 13:32:40.700: LISP: Processing received Encap-Control message from 10.1.47.7 to 10.1.34.4
*Oct 16 13:32:40.702: LISP: Processing received Map-Request message from 10.1.12.1 to 172.16.4.4
*Oct 16 13:32:40.702: LISP: Received map request for IID 0 172.16.4.4/32, source_eid IID 0 172.16.1.1, ITR-RLOCs: 10.1.12.1, records 1, nonce 0x188823A0-0xAFF029C8
*Oct 16 13:32:40.702: LISP: Processing map request record for EID prefix IID 0 172.16.4.4/32
*Oct 16 13:32:40.702: LISP-0: Sending map-reply from 10.1.34.4 to 10.1.12.1.

Packet Captures

On MR

Below packet capture is for Map-Request coming from R1 for R4:

Internet Protocol Version 4, Src: 10.1.15.1 (10.1.15.1), Dst: 192.168.5.5 (192.168.5.5)
    Version: 4
    Header Length: 20 bytes
    Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
    Total Length: 120
    Identification: 0x1446 (5190)
    Flags: 0x00
    Fragment offset: 0
    Time to live: 31
    Protocol: UDP (17)
    Header checksum: 0xa7c0 [validation disabled]
    Source: 10.1.15.1 (10.1.15.1)
    Destination: 192.168.5.5 (192.168.5.5)
    [Source GeoIP: Unknown]
    [Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 4342 (4342), Dst Port: 4342 (4342)
Locator/ID Separation Protocol
Internet Protocol Version 4, Src: 10.1.12.1 (10.1.12.1), Dst: 172.16.4.4 (172.16.4.4)
    Version: 4
    Header Length: 20 bytes
    Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
    Total Length: 88
    Identification: 0x1445 (5189)
    Flags: 0x00
    Fragment offset: 0
    Time to live: 32
    Protocol: UDP (17)
    Header checksum: 0xbf7a [validation disabled]
    Source: 10.1.12.1 (10.1.12.1)
    Destination: 172.16.4.4 (172.16.4.4)
    [Source GeoIP: Unknown]
    [Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 4342 (4342), Dst Port: 4342 (4342)
Locator/ID Separation Protocol
On MS

Map-register packet is captured below:

Internet Protocol Version 4, Src: 10.1.47.4 (10.1.47.4), Dst: 192.168.7.7 (192.168.7.7)
User Datagram Protocol, Src Port: 4342 (4342), Dst Port: 4342 (4342)
Locator/ID Separation Protocol
    0011 .... .... .... .... .... = Type: Map-Register (3)
    .... 0... .... .... .... .... = P bit (Proxy-Map-Reply): Not set
    .... .0.. .... .... .... .... = S bit (LISP-SEC capable): Not set
    .... ..1. .... .... .... .... = I bit (xTR-ID present): Set
    .... ...0 .... .... .... .... = R bit (Built for an RTR): Not set
    .... .... 0000 0000 0000 000. = Reserved bits: 0x000000
    .... .... .... .... .... ...1 = M bit (Want-Map-Notify): Set
    Record Count: 1
    Nonce: 0x56d89121c39c2892
    Key ID: 0x0001
    Authentication Data Length: 20
    Authentication Data&colon; ce8f37f14c76d49e52717d1c5407e638e2733015
    Mapping Record 1, EID Prefix: 172.16.4.4/32, TTL: 1440, Action: No-Action, Authoritative
        Record TTL: 1440
        Locator Count: 1
        EID Mask Length: 32
        000. .... .... .... = Action: No-Action (0)
        ...1 .... .... .... = Authoritative bit: Set
        .... .000 0000 0000 = Reserved: 0x0000
        0000 .... .... .... = Reserved: 0x0000
        .... 0000 0000 0000 = Mapping Version: 0
        EID Prefix AFI: IPv4 (1)
        EID Prefix: 172.16.4.4 (172.16.4.4)
        Locator Record 1, Local RLOC: 10.1.34.4, Reachable, Priority/Weight: 1/100, Multicast Priority/Weight: 255/0
    xTR-ID: f7de6c9306f8dda47d6400b119ec9669
    Site-ID: 0000000000000000
On R1

Map-Reply message captured on R1 being received from R4

Internet Protocol Version 4, Src: 10.1.34.4 (10.1.34.4), Dst: 10.1.12.1 (10.1.12.1)
User Datagram Protocol, Src Port: 4342 (4342), Dst Port: 4342 (4342)
Locator/ID Separation Protocol
    0010 .... .... .... .... .... = Type: Map-Reply (2)
    .... 0... .... .... .... .... = P bit (Probe): Not set
    .... .0.. .... .... .... .... = E bit (Echo-Nonce locator reachability algorithm enabled): Not set
    .... ..0. .... .... .... .... = S bit (LISP-SEC capable): Not set
    .... ...0 0000 0000 0000 0000 = Reserved bits: 0x000000
    Record Count: 1
    Nonce: 0xe9ee73f07b0cb7d6
    Mapping Record 1, EID Prefix: 172.16.4.4/32, TTL: 1440, Action: No-Action, Authoritative
        Record TTL: 1440
        Locator Count: 1
        EID Mask Length: 32
        000. .... .... .... = Action: No-Action (0)
        ...1 .... .... .... = Authoritative bit: Set
        .... .000 0000 0000 = Reserved: 0x0000
        0000 .... .... .... = Reserved: 0x0000
        .... 0000 0000 0000 = Mapping Version: 0
        EID Prefix AFI: IPv4 (1)
        EID Prefix: 172.16.4.4 (172.16.4.4)
        Locator Record 1, Local RLOC: 10.1.34.4, Reachable, Priority/Weight: 1/100, Multicast Priority/Weight: 255/0

TAC Authored

Contributed by Cisco Engineers

  • Naveen Bansal
    Cisco TAC Engineer
  • Subeh Sharma
    Cisco TAC Engineer

Was this Document Helpful?

FeedbackFeedback

Contact Cisco

This Document Applies to These Products