+.. _lispflowmapping-user-guide:
+
LISP Flow Mapping User Guide
============================
advanced SDN and NFV use cases.
LISP data plane Tunnel Routers are available at
-`LISPmob.org <http://LISPmob.org/>`__ in the open source community on
+`OpenOverlayRouter.org <http://www.openoverlayrouter.org/>`__ in the open source community on
the following platforms:
- Linux
- OpenWRT
For more details and support for LISP data plane software please visit
-`the LISPmob web site <http://LISPmob.org/>`__.
+`the OOR web site <http://www.openoverlayrouter.org/>`__.
LISP Flow Mapping Service
~~~~~~~~~~~~~~~~~~~~~~~~~
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*)
Enables/disables the `Solicit-Map-Request
(SMR) <http://tools.ietf.org/html/rfc6830#section-6.6.2>`__
---------
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>`__
+
+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
-~~~~~~~~~~~~~~~~~~~~~~~
+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 LISPmob as data
+nodes (one "client" node and two "server" nodes) using OOR as data
plane LISP nodes and the LISP Flow Mapping project from OpenDaylight as
the LISP programmable mapping system for the LISP network.
Prerequisites
^^^^^^^^^^^^^
-- **OpenDaylight Beryllium**
+- **OpenDaylight Carbon**
+
+.. _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/beryllium``.
+ `<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 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.
-- **LISPmob version 0.5.x** The README.md lists the dependencies needed
+- **OOR version 1.0 or later** The README.md lists the dependencies needed
to build it from source.
- **A virtualization platform**
+==========================+==========================+==========================+
| **controller** | OpenDaylight | 192.168.16.11 |
+--------------------------+--------------------------+--------------------------+
-| **client** | LISPmob | 192.168.16.30 |
+| **client** | OOR | 192.168.16.30 |
+--------------------------+--------------------------+--------------------------+
-| **server1** | LISPmob | 192.168.16.31 |
+| **server1** | OOR | 192.168.16.31 |
+--------------------------+--------------------------+--------------------------+
-| **server2** | LISPmob | 192.168.16.32 |
+| **server2** | OOR | 192.168.16.32 |
+--------------------------+--------------------------+--------------------------+
-| **service-node** | LISPmob | 192.168.16.33 |
+| **service-node** | OOR | 192.168.16.33 |
+--------------------------+--------------------------+--------------------------+
Table: Nodes in the tutorial
+The figure below gives a sketch of network topology that will be used in the tutorial.
+
+.. figure:: ./images/tutorial_architecture_diagram.png
+ :alt: Network architecture of 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.
+
.. note::
- While the tutorial uses LISPmob as the data plane, it could be any
+ 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 Beryllium release on the controller VM.
- Please follow the general OpenDaylight Beryllium Installation Guide
+1. Install and run OpenDaylight Carbon release on the controller VM.
+ Please follow the general OpenDaylight Carbon Installation Guide
for this step. Once the OpenDaylight controller is running install
the *odl-lispflowmapping-msmr* feature from the Karaf CLI:
Karaf console to see when the log output is winding down, and
continue with the tutorial after that.
-2. Install LISPmob on the **client**, **server1**, **server2**, and
+2. Install OOR on the **client**, **server1**, **server2**, and
**service-node** VMs following the installation instructions `from
- the LISPmob README
- file <https://github.com/LISPmob/lispmob#software-prerequisites>`__.
-
-3. Configure the LISPmob installations from the previous step. Starting
- from the ``lispd.conf.example`` file in the distribution, set the
- EID in each ``lispd.conf`` file from the IP address space selected
+ the OOR README
+ file <https://github.com/OpenOverlayRouter/oor#software-prerequisites>`__.
+
+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 ``lispd.conf`` file. LISP
+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** 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.
-6. Modify the "key" parameter in each ``lispd.conf`` file to a
+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`` directory in the *stable/beryllium*
+ The ``resources/tutorial/OOR`` directory in the *stable/carbon*
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/stable/beryllium>`__,
- so you can just copy the files to ``/root/lispd.conf`` on the
+ in <https://git.opendaylight.org/gerrit/gitweb?p=lispflowmapping.git;a=tree;f=resources/tutorial/OOR;hb=refs/heads/stable/carbon>`__,
+ 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.
::
- curl -u "admin":"admin" -H "Content-type: application/json" -X POST \
- http://localhost:8181/restconf/operations/odl-mappingservice:add-key \
+ 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
{
- "input": {
+ "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"
::
- curl -u "admin":"admin" -H "Content-type: application/json" -X POST \
- http://localhost:8181/restconf/operations/odl-mappingservice:get-key \
- --data @get1.json
+ 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/
- where the content of the *get1.json* file can be derived from the
- *add-key.json* file by removing the *mapping-authkey* field. The
- output the above invocation should look like this:
+ The output the above invocation should look like this:
- ::
+ .. code:: json
- {"output":{"mapping-authkey":{"key-type":1,"key-string":"password"}}}
+ {
+ "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 ``lispd`` LISPmob daemon on all VMs:
+9. Run the ``oor`` OOR daemon on all VMs:
::
- lispd -f /root/lispd.conf
+ oor -f /etc/oor.conf
-10. The **client** LISPmob node should now register its EID-to-RLOC
+ For more information on accessing OOR logs, take a look at
+ `OOR README <https://github.com/OpenOverlayRouter/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 POST \
- http://localhost:8181/restconf/operations/odl-mappingservice:get-mapping \
- --data @get1.json
+ 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 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.
::
- curl -u "admin":"admin" -H "Content-type: application/json" -X POST \
- http://localhost:8181/restconf/operations/odl-mappingservice:add-mapping \
+ 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:
.. code:: json
{
- "input": {
+ "mapping": {
+ "eid-uri": "ipv4:2.2.2.2/32",
+ "origin": "northbound",
"mapping-record": {
"recordTtl": 1440,
"action": "NoAction",
::
- curl -u "admin":"admin" -H "Content-type: application/json" -X POST \
- http://localhost:8181/restconf/operations/odl-mappingservice:get-mapping \
- --data @get2.json
-
- where *get2.json* can be derived from *get1.json* by changing the
- content of the *Ipv4Address* field from *1.1.1.1* to *2.2.2.2*.
+ 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:
::
- curl -u "admin":"admin" -H "Content-type: application/json" -X POST \
- http://localhost:8181/restconf/operations/odl-mappingservice:add-mapping \
+ 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:
.. code:: json
{
- "input": {
+ "mapping": {
+ "eid-uri": "ipv4:2.2.2.2/32",
+ "origin": "northbound",
"mapping-record": {
"recordTtl": 1440,
"action": "NoAction",
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 LISPmob logs, or by
+ **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
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 LISPmob community to allow filtering on EIDs,
+ 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,
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;hb=HEAD>`__.
+
+Prerequisites
+^^^^^^^^^^^^^
+
+- **OpenDaylight Carbon**
+
+- **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=HEAD>`__.
+
+- **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 Carbon release on the VM. Please
+ follow the general OpenDaylight Carbon 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/carbon>`__.
+ 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/carbon>`__.
+ 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/carbon>`__.
+
+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
+
LISP Flow Mapping Support
-------------------------
Code Review / docs.git / blobdiff