+.. _lispflowmapping-user-guide:
+
LISP Flow Mapping User Guide
============================
query mappings to the LISP Flow Mapping via the LISP control plane
protocol.
+.. _lfm_config:
+
Configuring LISP Flow Mapping
-----------------------------
configuration of several OpenDaylight parameters. The LISP service has
the following properties that can be adjusted:
-**lisp.mappingOverwrite** (default: *true*)
- Configures handling of mapping updates. When set to *true* (default)
- a mapping update (either through the southbound plugin via a
- Map-Register message or through a northbound API PUT REST call) the
- existing RLOC set associated to an EID prefix is overwritten. When
- set to *false*, the RLOCs of the update are merged to the existing
- set.
-
-**lisp.smr** (default: *false*)
+**lisp.smr** (default: *true*)
Enables/disables the `Solicit-Map-Request
(SMR) <http://tools.ietf.org/html/rfc6830#section-6.6.2>`__
functionality. SMR is a method to notify changes in an EID-to-RLOC
---------
This section provides a tutorial demonstrating various features in this
-service.
+service. We have included tutorials using two forwarding platforms:
+
+1. Using `Open Overlay Router (OOR) <https://github.com/OpenOverlayRouter/oor#overview>`__
+
+2. Using `FD.io <https://wiki.fd.io/view/ONE>`__
-Creating a LISP overlay
-~~~~~~~~~~~~~~~~~~~~~~~
+Both have different approaches to create the overlay but ultimately do the
+same job. Details of both approaches have been explained below.
+
+Creating a LISP overlay with OOR
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This section provides instructions to set up a LISP network of three
nodes (one "client" node and two "server" nodes) using OOR as data
Prerequisites
^^^^^^^^^^^^^
-- **OpenDaylight Boron**
+- **The OpenDaylight Karaf Distribution** (`download
+ <https://www.opendaylight.org/downloads>`_)
+
+.. _instructions:
- **The Postman Chrome App**: the most convenient way to follow along
- this tutorial is to use the `Postman Chrome
- App <https://chrome.google.com/webstore/detail/postman/fhbjgbiflinjbdggehcddcbncdddomop?hl=en>`__
+ this tutorial is to use the `Postman
+ App <https://www.getpostman.com/apps>`__
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/Beryllium_Tutorial.json.postman_collection``
+ ``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/Beryllium_Tutorial.json.postman_collection;hb=refs/heads/stable/boron``.
+ `<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/oxygen>`__.
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 ODL instance, and ``restconfPort`` to 8181, if you didn’t
+ 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
In LISP terminology **client**, **server1** and **server2** are mobile nodes (MN in OOR),
**controller** is a MS/MR and **service-node** is a RTR.
-.. note::
-
- While the tutorial uses OOR as the data plane, it could be any
- LISP-enabled hardware or software router (commercial/open source).
-
Instructions
^^^^^^^^^^^^
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 OpenDaylight Boron release on the controller VM.
- Please follow the general OpenDaylight Boron Installation Guide
+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:
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** set the Map-Server to something else, so
+ **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.
.. note::
- The ``resources/tutorial`` directory in the *stable/boron*
- branch of the project git repository has the files used in the
- tutorial `checked
- in <https://git.opendaylight.org/gerrit/gitweb?p=lispflowmapping.git;a=tree;f=resources/tutorial;hb=refs/heads/master>`__,
- 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.
+ The ``resources/tutorial/OOR`` directory in the project git repository
+ has the files used in the tutorial `checked in
+ <https://git.opendaylight.org/gerrit/gitweb?p=lispflowmapping.git;a=tree;f=resources/tutorial/OOR;hb=refs/heads/stable/oxygen>`_,
+ 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
::
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:1.1.1.1%2f32/southbound/
+ 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 ODL using the
+ An alternative way for retrieving mappings from OpenDaylight using the
southbound interface is using the
- ```lig`` <https://github.com/davidmeyer/lig>`__ open source tool.
+ `lig <https://github.com/davidmeyer/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
which should restore connectivity.
+
+Creating a simple LISP overlay with FD.io
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+In this section, we use the Overlay Network Engine (ONE) project in FD.io
+to facilitate fully scripted setup and testing of a LISP/VXLAN-GPE network.
+Overlay Network Engine (ONE) is a `FD.io <https://fd.io/>`__ project that enables programmable
+dynamic software defined overlays. Details about this project can be
+found in `ONE wiki <https://wiki.fd.io/view/ONE>`__.
+
+The steps shown below will demonstrate setting up a LISP network between
+a client and a server using VPP. We demonstrate how to use VPP lite to
+build a IP4 LISP overlay on an Ubuntu host using namespaces and af_packet
+interfaces. All configuration files used in the tutorials can be found
+`here <https://gerrit.fd.io/r/gitweb?p=one.git;a=tree;f=tutorial>`__.
+
+Prerequisites
+^^^^^^^^^^^^^
+
+- **The OpenDaylight Karaf Distribution** (`download
+ <https://www.opendaylight.org/downloads>`_)
+
+- **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/oxygen>`__.
+
+- **Vagrant** (optional): Download it from `Vagrant website <https://www.vagrantup.com/downloads.html>`__
+ 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**.
+
++--------------------------+--------------------------+--------------------------+
+| Node | Node Type | IP Address |
++==========================+==========================+==========================+
+| **controller** | OpenDaylight | 6.0.3.100 |
++--------------------------+--------------------------+--------------------------+
+| **client** | VPP | 6.0.2.2 |
++--------------------------+--------------------------+--------------------------+
+| **server** | VPP | 6.0.4.4 |
++--------------------------+--------------------------+--------------------------+
+| **service node** | VPP | 6.0.3.3 |
++--------------------------+--------------------------+--------------------------+
+
+Table: Nodes in the tutorial
+
+The figure below gives a sketch of network topology that will be used in the tutorial.
+
+.. figure:: ./images/one_ODL_architecture.png
+ :alt: Network architecture of the tutorial for FD.io
+
+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 <https://wiki.fd.io/view/VPP/Build,_install,_and_test_images>`__
+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 :ref:`install_odl`.
+ 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 :ref:`lfm_config`.
+ 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
+ <https://git.opendaylight.org/gerrit/gitweb?p=lispflowmapping.git;a=tree;f=resources/tutorial/FD_io;hb=refs/heads/stable/oxygen>`__.
+ 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:
+
+ .. code:: 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:
+
+ .. code:: 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
+ <https://git.opendaylight.org/gerrit/gitweb?p=lispflowmapping.git;a=tree;f=resources/tutorial/FD_io;hb=refs/heads/stable/oxygen>`__.
+ 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 <https://git.opendaylight.org/gerrit/gitweb?p=lispflowmapping.git;a=tree;f=resources/tutorial/FD_io;hb=refs/heads/stable/oxygen>`__.
+
+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
+
+Creating a LISP overlay with Cisco IOS-XE
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This section describes how to create a simple LISP overlay using the Cisco
+IOS-XE network operating system as the data plane software running on the
+`Cisco CSR 1000v Series Cloud Services Router
+<http://www.cisco.com/c/en/us/support/routers/cloud-services-router-1000v/model.html>`_.
+
+Prerequisites
+^^^^^^^^^^^^^
+
+- **The OpenDaylight Karaf Distribution** (`download
+ <https://www.opendaylight.org/downloads>`_)
+
+- **CSR1Kv image with Cisco IOS-XE version 03.13.00.S or later** (`download
+ <http://www.cisco.com/c/en/us/support/routers/cloud-services-router-1000v/model.html#~tab-downloads>`_;
+ 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):
+
++--------------------------+--------------------------+--------------------------+
+| Node | Node Type | IP Address |
++==========================+==========================+==========================+
+| **controller** | OpenDaylight | 192.168.16.11 |
++--------------------------+--------------------------+--------------------------+
+| **client** | CSR1Kv | 192.168.16.30 |
++--------------------------+--------------------------+--------------------------+
+| **server** | CSR1Kv | 192.168.16.31 |
++--------------------------+--------------------------+--------------------------+
+
+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
+ :ref:`install_odl` 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
+ <http://www.cisco.com/c/en/us/td/docs/routers/csr1000/software/configuration/b_CSR1000v_Configuration_Guide.html>`_.
+
+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:
+
+ .. code:: json
+
+ {
+ "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:
+
+ .. code:: json
+
+ {
+ "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 <https://github.com/davidmeyer/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
+
LISP Flow Mapping Support
-------------------------
Code Review / docs.git / blobdiff