LISP Flow Mapping User Guide¶

Overview¶

The steps shown below will demonstrate setting up a LISP network between a client and two servers, then performing a failover between the two “server” nodes.

Prerequisites¶

• The OpenDaylight Karaf Distribution (download)

• The Postman Chrome App: the most convenient way to follow along this tutorial is to use the Postman App to edit and send the requests. The project git repository hosts a collection of the requests that are used in this tutorial in the resources/tutorial/OOR/Beryllium_Tutorial.json.postman_collection file. You can import this file to Postman by clicking Import at the top, choosing Download from link and then entering the following URL: https://git.opendaylight.org/gerrit/gitweb?p=lispflowmapping.git;a=blob_plain;f=resources/tutorial/OOR/Beryllium_Tutorial.json.postman_collection;hb=refs/heads/stable/carbon. Alternatively, you can save the file on your machine, or if you have the repository checked out, you can import from there. You will need to create a new Postman Environment and define some variables within: controllerHost set to the hostname or IP address of the machine running the OpenDaylight instance, and restconfPort to 8181, if you didn’t modify the default controller settings.
• OOR version 1.0 or later The README.md lists the dependencies needed to build it from source.
• A virtualization platform

Target Environment¶

The three LISP data plane nodes and the LISP mapping system are assumed to be running in Linux virtual machines, which have the eth0 interface in NAT mode to allow outside internet access and eth1 connected to a host-only network, with the following IP addresses (please adjust configuration files, JSON examples, etc. accordingly if you’re using another addressing scheme):

Table: Nodes in the tutorial

The figure below gives a sketch of network topology that will be used in the tutorial.

In LISP terminology client, server1 and server2 are mobile nodes (MN in OOR), controller is a MS/MR and service-node is a RTR.

Instructions¶

The below steps use the command line tool cURL to talk to the LISP Flow Mapping RPC REST API. This is so that you can see the actual request URLs and body content on the page.

1. Install and run the OpenDaylight distribution on the controller VM. Please follow the general OpenDaylight Installation Guide for this step. Once the OpenDaylight controller is running install the odl-lispflowmapping-msmr feature from the Karaf CLI:

   feature:install odl-lispflowmapping-msmr
   

   It takes quite a while to load and initialize all features and their dependencies. It’s worth running the command log:tail in the Karaf console to see when the log output is winding down, and continue with the tutorial after that.

2. Install OOR on the client, server1, server2, and service-node VMs following the installation instructions from the OOR README file.

3. Configure the OOR installations from the previous step. Take a look at the oor.conf.example to get a general idea of the structure of the conf file. First, check if the file /etc/oor.conf exists. If the file doesn’t exist, create the file /etc/oor.conf. Set the EID in /etc/oor.conf file from the IP address space selected for your virtual/LISP network. In this tutorial the EID of the client is set to 1.1.1.1/32, and that of server1 and server2 to 2.2.2.2/32.

4. Set the RLOC interface to eth1 in each oor.conf file. LISP will determine the RLOC (IP address of the corresponding VM) based on this interface.

5. Set the Map-Resolver address to the IP address of the controller, and on the client the Map-Server too. On server1 and server2 remove the Map-Server configuration, so that it doesn’t interfere with the mappings on the controller, since we’re going to program them manually.

6. Modify the “key” parameter in each oor.conf file to a key/password of your choice (password in this tutorial).

   Note

   The resources/tutorial/OOR directory in the project git repository has the files used in the tutorial checked in, so you can just copy the files to /etc/oor.conf on the respective VMs. You will also find the JSON files referenced below in the same directory.

7. Define a key and EID prefix association in OpenDaylight using the RPC REST API for the client EID (1.1.1.1/32) to allow registration from the southbound. Since the mappings for the server EID will be configured from the REST API, no such association is necessary. Run the below command on the controller (or any machine that can reach controller, by replacing localhost with the IP address of controller).

   curl -u "admin":"admin" -H "Content-type: application/json" -X PUT \
       http://localhost:8181/restconf/config/odl-mappingservice:mapping-database/virtual-network-identifier/0/authentication-key/ipv4:1.1.1.1%2f32/ \
       --data @add-key.json
   

   where the content of the add-key.json file is the following:

   {
       "authentication-key": {
           "eid-uri": "ipv4:1.1.1.1/32",
           "eid": {
               "address-type": "ietf-lisp-address-types:ipv4-prefix-afi",
               "ipv4-prefix": "1.1.1.1/32"
           },
           "mapping-authkey": {
               "key-string": "password",
               "key-type": 1
           }
       }
   }
   

8. Verify that the key is added properly by requesting the following URL:

   curl -u "admin":"admin" -H "Content-type: application/json" -X GET \
       http://localhost:8181/restconf/config/odl-mappingservice:mapping-database/virtual-network-identifier/0/authentication-key/ipv4:1.1.1.1%2f32/
   

   The output the above invocation should look like this:

   {
       "authentication-key":[
           {
               "eid-uri":"ipv4:1.1.1.1/32",
               "eid":{
                   "ipv4-prefix":"1.1.1.1/32",
                   "address-type":"ietf-lisp-address-types:ipv4-prefix-afi"
               },
               "mapping-authkey":{
                   "key-string":"password"
                   ,"key-type":1
               }
           }
       ]
   }
   

9. Run the oor OOR daemon on all VMs:

   oor -f /etc/oor.conf
   

   For more information on accessing OOR logs, take a look at OOR README

10. The client OOR node should now register its EID-to-RLOC mapping in OpenDaylight. To verify you can lookup the corresponding EIDs via the REST API

    curl -u "admin":"admin" -H "Content-type: application/json" -X GET \
        http://localhost:8181/restconf/operational/odl-mappingservice:mapping-database/virtual-network-identifier/0/mapping/ipv4:1.1.1.1%2f32/southbound/
    

    An alternative way for retrieving mappings from OpenDaylight using the southbound interface is using the lig open source tool.

11. Register the EID-to-RLOC mapping of the server EID 2.2.2.2/32 to the controller, pointing to server1 and server2 with a higher priority for server1

    curl -u "admin":"admin" -H "Content-type: application/json" -X PUT \
        http://localhost:8181/restconf/config/odl-mappingservice:mapping-database/virtual-network-identifier/0/mapping/ipv4:2.2.2.2%2f32/northbound/ \
        --data @mapping.json
    

    where the mapping.json file looks like this:

    {
        "mapping": {
            "eid-uri": "ipv4:2.2.2.2/32",
            "origin": "northbound",
            "mapping-record": {
                "recordTtl": 1440,
                "action": "NoAction",
                "authoritative": true,
                "eid": {
                    "address-type": "ietf-lisp-address-types:ipv4-prefix-afi",
                    "ipv4-prefix": "2.2.2.2/32"
                },
                "LocatorRecord": [
                    {
                        "locator-id": "server1",
                        "priority": 1,
                        "weight": 1,
                        "multicastPriority": 255,
                        "multicastWeight": 0,
                        "localLocator": true,
                        "rlocProbed": false,
                        "routed": true,
                        "rloc": {
                            "address-type": "ietf-lisp-address-types:ipv4-afi",
                            "ipv4": "192.168.16.31"
                        }
                    },
                    {
                        "locator-id": "server2",
                        "priority": 2,
                        "weight": 1,
                        "multicastPriority": 255,
                        "multicastWeight": 0,
                        "localLocator": true,
                        "rlocProbed": false,
                        "routed": true,
                        "rloc": {
                            "address-type": "ietf-lisp-address-types:ipv4-afi",
                            "ipv4": "192.168.16.32"
                        }
                    }
                ]
            }
        }
    }
    

    Here the priority of the second RLOC (192.168.16.32 - server2) is 2, a higher numeric value than the priority of 192.168.16.31, which is 1. This policy is saying that server1 is preferred to server2 for reaching EID 2.2.2.2/32. Note that lower priority value has higher preference in LISP.

12. Verify the correct registration of the 2.2.2.2/32 EID:

    curl -u "admin":"admin" -H "Content-type: application/json" -X GET \
        http://localhost:8181/restconf/config/odl-mappingservice:mapping-database/virtual-network-identifier/0/mapping/ipv4:2.2.2.2%2f32/northbound/
    

13. Now the LISP network is up. To verify, log into the client VM and ping the server EID:

    ping 2.2.2.2
    

14. Let’s test fail-over now. Suppose you had a service on server1 which became unavailable, but server1 itself is still reachable. LISP will not automatically fail over, even if the mapping for 2.2.2.2/32 has two locators, since both locators are still reachable and uses the one with the higher priority (lowest priority value). To force a failover, we need to set the priority of server2 to a lower value. Using the file mapping.json above, swap the priority values between the two locators (lines 14 and 28 in mapping.json) and repeat the request from step 11. You can also repeat step 12 to see if the mapping is correctly registered. If you leave the ping on, and monitor the traffic using wireshark, you can see that the ping traffic to 2.2.2.2 will be diverted from the server1 RLOC to the server2 RLOC.

    With the default OpenDaylight configuration the failover should be near instantaneous (we observed 3 lost pings in the worst case), because of the LISP Solicit-Map-Request (SMR) mechanism that can ask a LISP data plane element to update its mapping for a certain EID (enabled by default). It is controlled by the lisp.smr variable in etc/custom.porperties. When enabled, any mapping change from the RPC interface will trigger an SMR packet to all data plane elements that have requested the mapping in the last 24 hours (this value was chosen because it’s the default TTL of Cisco IOS xTR mapping registrations). If disabled, ITRs keep their mappings until the TTL specified in the Map-Reply expires.

15. To add a service chain into the path from the client to the server, we can use an Explicit Locator Path, specifying the service-node as the first hop and server1 (or server2) as the second hop. The following will achieve that:

    curl -u "admin":"admin" -H "Content-type: application/json" -X PUT \
        http://localhost:8181/restconf/config/odl-mappingservice:mapping-database/virtual-network-identifier/0/mapping/ipv4:2.2.2.2%2f32/northbound/ \
        --data @elp.json
    

    where the elp.json file is as follows:

    {
        "mapping": {
            "eid-uri": "ipv4:2.2.2.2/32",
            "origin": "northbound",
            "mapping-record": {
                "recordTtl": 1440,
                "action": "NoAction",
                "authoritative": true,
                "eid": {
                    "address-type": "ietf-lisp-address-types:ipv4-prefix-afi",
                    "ipv4-prefix": "2.2.2.2/32"
                },
                "LocatorRecord": [
                    {
                        "locator-id": "ELP",
                        "priority": 1,
                        "weight": 1,
                        "multicastPriority": 255,
                        "multicastWeight": 0,
                        "localLocator": true,
                        "rlocProbed": false,
                        "routed": true,
                        "rloc": {
                            "address-type": "ietf-lisp-address-types:explicit-locator-path-lcaf",
                            "explicit-locator-path": {
                                "hop": [
                                    {
                                        "hop-id": "service-node",
                                        "address": "192.168.16.33",
                                        "lrs-bits": "strict"
                                    },
                                    {
                                        "hop-id": "server1",
                                        "address": "192.168.16.31",
                                        "lrs-bits": "strict"
                                    }
                                ]
                            }
                        }
                    }
                ]
            }
        }
    }
    

    After the mapping for 2.2.2.2/32 is updated with the above, the ICMP traffic from client to server1 will flow through the service-node. You can confirm this in the OOR logs, or by sniffing the traffic on either the service-node or server1. Note that service chains are unidirectional, so unless another ELP mapping is added for the return traffic, packets will go from server1 to client directly.

16. Suppose the service-node is actually a firewall, and traffic is diverted there to support access control lists (ACLs). In this tutorial that can be emulated by using iptables firewall rules in the service-node VM. To deny traffic on the service chain defined above, the following rule can be added:

    iptables -A OUTPUT --dst 192.168.16.31 -j DROP
    

    The ping from the client should now have stopped.

    In this case the ACL is done on the destination RLOC. There is an effort underway in the OOR community to allow filtering on EIDs, which is the more logical place to apply ACLs.

17. To delete the rule and restore connectivity on the service chain, delete the ACL by issuing the following command:

    iptables -D OUTPUT --dst 192.168.16.31 -j DROP
    

    which should restore connectivity.

Prerequisites¶

• The OpenDaylight Karaf Distribution (download)
• The Postman Chrome App: Please follow the instructions and import postman collection from the following URL: https://git.opendaylight.org/gerrit/gitweb?p=lispflowmapping.git;a=blob;f=resources/tutorial/FD_io/lfm_vpp.postman_collection.json;hb=refs/heads/stable/carbon.
• Vagrant (optional): Download it from Vagrant website and follow the setup instructions.

Target Environment¶

Unlike the case with OOR, we use network namespace functionality of Linux to create the overlay in this case. The following table contains ip addresses of nodes in the overlay topology used in the tutorial. Our objective will be to create this topology and be able to ping from client to server through an intermediary hop, service node, which is a rtr node providing the service of re-encapsulation. So, all the packets from client to server will be through this service node.

Table: Nodes in the tutorial

The figure below gives a sketch of network topology that will be used in the tutorial.

Instructions¶

Follow the instructions below sequentially.

1. Pull the VPP code anonymously using:

   git clone https://gerrit.fd.io/r/vpp
   

2. Then, use the vagrant file from repository to build virtual machine with proper environment.

   cd vpp/build-root/vagrant/
   vagrant up
   vagrant ssh
   

3. In case there is any error from vagrant up, try vargant ssh. if it works, no worries. If it still doesn’t work, you can try any Ubuntu virtual machine. Or sometimes there is an issue with the Vagrant properly copying the VPP repo code from the host VM after the first installation. In that case /vpp doesn’t exist. In both cases, follow the instructions from below.

   1. Clone the code in / directory. So, the codes will be in /vpp.

   2. Run the following commands:

      cd /vpp/build-root
      make distclean
      ./bootstrap.sh
      make V=0 PLATFORM=vpp TAG=vpp install-deb
      sudo dpkg -i /vpp/build-root/*.deb
      

   Alternative and more detailed build instructions can be found in VPP’s wiki

4. By now, you should have a Ubuntu VM with VPP repository in /vpp with sudo access. Now, we need VPP Lite build. The following commands builds VPP Lite.

   cd /vpp
   export PLATFORM=vpp_lite
   make build
   

   Successful build create the binary in /vpp/build-root/install-vpp_lite_debug-native/vpp/bin

5. Install bridge-utils and ethtool if needed by using following commands:

   sudo apt-get install bridge-utils ethtool
   

6. Now, install and run OpenDaylight on the VM. Please follow the general OpenDaylight Installation Guide for this step from Installing OpenDaylight. Before running OpenDaylight, we need to change the configuration for RTR to work. Update etc/custom.properties with the lisp.elpPolicy to be replace.

   lisp.elpPolicy = replace
   

   Then, run OpenDaylight. For details regarding configuring LISP Flow Mapping, please take a look at Configuring LISP Flow Mapping. Once the OpenDaylight controller is running install the odl-lispflowmapping-msmr feature from the Karaf CLI:

   feature:install odl-lispflowmapping-msmr
   

   It may take quite a while to load and initialize all features and their dependencies. It’s worth running the command log:tail in the Karaf console to see when the log output is winding down, and continue with the tutorial after that.

7. For setting up VPP, get the files from resources/tutorial/FD_io folder of the lispflowmapping repo. The files can also be found here. Copy the vpp1.config, vpp2.config and rtr.config files in /etc/vpp/lite/.

8. In this example, VPP doesn’t make any southbound map registers to OpenDaylight. So, we add the mappings directly from northbound. For that, we need to add the mappings to OpenDaylight via RESTCONF API.

   Register EID-to-RLOC mapping of the Client EID 6.0.2.0/24.

   curl -u "admin":"admin" -H "Content-type: application/json" -X PUT \
       http://localhost:8181/restconf/config/odl-mappingservice:mapping-database/virtual-network-identifier/0/mapping/ipv4:6.0.2.0%2f24/northbound/ \
       --data @epl1.json
   

   Content of epl1.json:

   {
       "mapping": {
           "eid-uri": "ipv4:6.0.2.0/24",
           "origin": "northbound",
           "mapping-record": {
               "recordTtl": 1440,
               "action": "NoAction",
               "authoritative": true,
               "eid": {
                       "address-type": "ietf-lisp-address-types:ipv4-prefix-afi",
                       "ipv4-prefix": "6.0.2.0/24"
               },
               "LocatorRecord": [
                   {
                       "locator-id": "ELP",
                       "priority": 1,
                       "weight": 1,
                       "multicastPriority": 255,
                       "multicastWeight": 0,
                       "localLocator": true,
                       "rlocProbed": false,
                       "routed": false,
                       "rloc": {
                           "address-type": "ietf-lisp-address-types:explicit-locator-path-lcaf",
                           "explicit-locator-path": {
                               "hop": [
                                   {
                                       "hop-id": "Hop 1",
                                       "address": "6.0.3.3",
                                       "lrs-bits": "lookup rloc-probe strict"
                                   },
                                   {
                                       "hop-id": "Hop 2",
                                       "address": "6.0.3.1",
                                       "lrs-bits": "lookup strict"
                                   }
                               ]
                           }
                       }
                   }
               ]
           }
       }
   }
   

   Similarly add EID-to-RLOC mapping of the Server EID 6.0.4.0/24.

   curl -u "admin":"admin" -H "Content-type: application/json" -X PUT \
       http://localhost:8181/restconf/config/odl-mappingservice:mapping-database/virtual-network-identifier/0/mapping/ipv4:6.0.4.0%2f24/northbound/ \
       --data @epl2.json
   

   Content of elp2.json:

   {
       "mapping": {
           "eid-uri": "ipv4:6.0.4.0/24",
           "origin": "northbound",
           "mapping-record": {
               "recordTtl": 1440,
               "action": "NoAction",
               "authoritative": true,
               "eid": {
                       "address-type": "ietf-lisp-address-types:ipv4-prefix-afi",
                       "ipv4-prefix": "6.0.4.0/24"
               },
               "LocatorRecord": [
                   {
                       "locator-id": "ELP",
                       "priority": 1,
                       "weight": 1,
                       "multicastPriority": 255,
                       "multicastWeight": 0,
                       "localLocator": true,
                       "rlocProbed": false,
                       "routed": false,
                       "rloc": {
                           "address-type": "ietf-lisp-address-types:explicit-locator-path-lcaf",
                           "explicit-locator-path": {
                               "hop": [
                                   {
                                       "hop-id": "Hop 1",
                                       "address": "6.0.3.3",
                                       "lrs-bits": "lookup rloc-probe strict"
                                   },
                                   {
                                       "hop-id": "Hop 2",
                                       "address": "6.0.3.2",
                                       "lrs-bits": "lookup strict"
                                   }
                               ]
                           }
                       }
                   }
               ]
           }
       }
   }
   

   The JSON files regarding these can be found in here. Even though there is no southbound registration for mapping to OpenDaylight, using northbound policy we can specify mappings, when Client requests for the Server eid, Client gets a reply from OpenDaylight.

9. Assuming all files have been created and OpenDaylight has been configured as explained above, execute the host script you’ve created or the topology_setup.sh script from here.

10. If all goes well, you can now test connectivity between the namespaces with:

    sudo ip netns exec vpp-ns1 ping 6.0.4.4
    

11. Traffic and control plane message exchanges can be checked with a wireshark listening on the odl interface.

12. Important

    Delete the topology by running the topology_setup.sh with clean argument.

    sudo ./topology_setup.sh clean
    

Prerequisites¶

• The OpenDaylight Karaf Distribution (download)
• CSR1Kv image with Cisco IOS-XE version 03.13.00.S or later (download; the instructions have been tested on version 03.15.00.S).
• A virtualization platform supported by CSR1Kv images (VMware ESXi, Citrix XenServer, KVM, and Microsoft Hyper-V).

Target Environment¶

The CSR1Kv images are configured with one management interface (GigabitEthernet1), and another interface (GigabitEthernet2) connected to a host-only network on the virtualization platform, while the LISP mapping system is assumed to be running in a Linux virtual machine, which has the eth0 interface in NAT mode to allow outside internet access and eth1 connected to the host-only network, with the following IP addresses (please adjust configuration files, JSON examples, etc. accordingly if you’re using another addressing scheme):

Table: Nodes in the tutorial

The scenario and EID allocation is the same as the OOR scenario, except that there is no server2 and service-node (for now).

Before this tutorial can be followed, basic connectivity between the Linux VM and the CSRs should work on the host-only network.

Instructions¶

The below steps use the command line tool cURL to talk to the LISP Flow Mapping RPC REST API. This is so that you can see the actual request URLs and body content on the page. The easy way is to just use Postman.

1. Install and run the OpenDaylight distribution on the controller VM. Please follow the general OpenDaylight Installation Guide from Installing OpenDaylight for this step. Once the OpenDaylight controller is running install the odl-lispflowmapping-msmr feature from the Karaf CLI:

   feature:install odl-lispflowmapping-msmr
   

   It takes quite a while to load and initialize all features and their dependencies. It’s worth running the command log:tail in the Karaf console to see when the log output is winding down, and continue with the tutorial after that.

2. Create the client and server VMs following the installation instructions from the CSR1Kv Configuration Guide.

3. Define a key and EID prefix association in OpenDaylight using the RPC REST API for the client and server EIDs (1.1.1.1/32 and 2.2.2.2/32 respectively) to allow registration from the southbound. Run the below command on the controller (or any machine that can reach controller, by replacing localhost with the IP address of controller).

   curl -u "admin":"admin" -H "Content-type: application/json" -X PUT \
       http://localhost:8181/restconf/config/odl-mappingservice:mapping-database/virtual-network-identifier/0/authentication-key/ipv4:1.1.1.1%2f32/ \
       --data @add-key.json
   

   where the content of the add-key.json file is the following:

   {
       "authentication-key": {
           "eid-uri": "ipv4:1.1.1.1/32",
           "eid": {
               "address-type": "ietf-lisp-address-types:ipv4-prefix-afi",
               "ipv4-prefix": "1.1.1.1/32"
           },
           "mapping-authkey": {
               "key-string": "password",
               "key-type": 1
           }
       }
   }
   

   The same should be done for 2.2.2.2/32 too.

4. Verify that the key is added properly by requesting the following URL:

   curl -u "admin":"admin" -H "Content-type: application/json" -X GET \
       http://localhost:8181/restconf/config/odl-mappingservice:mapping-database/virtual-network-identifier/0/authentication-key/ipv4:1.1.1.1%2f32/
   

   The output the above invocation should look like this:

   {
       "authentication-key":[
           {
               "eid-uri":"ipv4:1.1.1.1/32",
               "eid":{
                   "ipv4-prefix":"1.1.1.1/32",
                   "address-type":"ietf-lisp-address-types:ipv4-prefix-afi"
               },
               "mapping-authkey":{
                   "key-string":"password"
                   ,"key-type":1
               }
           }
       ]
   }
   

5. Configure the CSR installations from the previous step. The EID needs to be configured on a loopback interface (except when the CSR is used as a router not a simple client like in this tutorial and the EID is assigned to a real interface).

   interface Loopback0
    ip address 1.1.1.1 255.255.255.255
   

6. The LISP specific configuration goes to a router lisp section in the configuration. A locator-set defines the list of locators with their priorities and weights, either statically, or better yet, as an interface name:

   locator-set rloc-network
    IPv4-interface GigabitEthernet2 priority 1 weight 1
    exit
   

7. To make sure a Map-Request is using the above defined rloc-network locator set, the following configuration is used:

   map-request itr-rlocs rloc-network
   

8. Each Instance ID needs its own configuration. For the default Instance ID of 0, the following configuration is needed for a besic setup:

   eid-table default instance-id 0
    database-mapping 1.1.1.1/32 locator-set rloc-network
    map-cache 0.0.0.0/0 map-request
    no ipv4 map-cache-persistent
    ipv4 itr map-resolver 192.168.16.11
    ipv4 itr
    ipv4 etr map-server 192.168.16.11 key password
    ipv4 etr
    exit
   

   database-mapping defines the EID prefix the router will register in the mapping system and which locator set it will use (rloc-network in this case, which was defined in step 6).

   The next line creates a static map-cache entry for the whole IPv4 EID space, causing a Map-Request to be triggered for every destination (that is not directly connected on some interface).

   LISP routers save their map cache to a fie which is used to restore previous state on reboot. To avoid confusion due to state restored from a previous run, no ipv4 map-cache-persistent can be used to disable this behavior for non-production testing environments.

   A map-resolver is then defined, where Map-Requests will be directed to for mapping lookups, and then a map-server association with a shared secret key.

9. Here’s the full configuration that needs to be pasted into the configuration of the client to follow this tutorial:

   interface Loopback0
    ip address 1.1.1.1 255.255.255.255
   !
   router lisp
    locator-set rloc-network
     IPv4-interface GigabitEthernet2 priority 1 weight 1
     exit
    !
    map-request itr-rlocs rloc-network
    eid-table default instance-id 0
     database-mapping 1.1.1.1/32 locator-set rloc-network
     map-cache 0.0.0.0/0 map-request
     no ipv4 map-cache-persistent
     ipv4 itr map-resolver 192.168.16.11
     ipv4 itr
     ipv4 etr map-server 192.168.16.11 key password
     ipv4 etr
     exit
    !
    exit
   

   Configuring the server is done by replacing 1.1.1.1 with 2.2.2.2 in the above configuration snippet.

10. The CSR nodes should now register their EID-to-RLOC mappings to OpenDaylight. To verify, the corresponding EIDs can be looked up via the REST API:

    curl -u "admin":"admin" -H "Content-type: application/json" -X GET \
        http://localhost:8181/restconf/operational/odl-mappingservice:mapping-database/virtual-network-identifier/0/mapping/ipv4:1.1.1.1%2f32/southbound/
    

    An alternative way for retrieving mappings from OpenDaylight using the southbound interface is using the lig open source tool.

    Yet another different way is to use the OpenDaylight mappingservice CLI, and type the following at the Karaf prompt:

    mappingservice:mappings
    

    This needs the odl-lispflowmapping-mappingservice-shell feature to be loaded. The output is intended for debugging purposes and shows the full Java objects stored in the map-cache.

11. Now the LISP network is up. It can be verified by pinging the server EID from the client CSR EID:

    ping 2.2.2.2 source 1.1.1.1