1 LISP Flow Mapping User Guide
2 ============================
7 Locator/ID Separation Protocol
8 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
10 `Locator/ID Separation Protocol
11 (LISP) <http://tools.ietf.org/html/rfc6830>`__ is a technology that
12 provides a flexible map-and-encap framework that can be used for overlay
13 network applications such as data center network virtualization and
14 Network Function Virtualization (NFV).
16 LISP provides the following name spaces:
18 - `Endpoint Identifiers
19 (EIDs) <http://tools.ietf.org/html/rfc6830#page-6>`__
22 (RLOCs) <http://tools.ietf.org/html/rfc6830#section-3>`__
24 In a virtualization environment EIDs can be viewed as virtual address
25 space and RLOCs can be viewed as physical network address space.
27 The LISP framework decouples network control plane from the forwarding
30 - A data plane that specifies how the virtualized network addresses are
31 encapsulated in addresses from the underlying physical network.
33 - A control plane that stores the mapping of the virtual-to-physical
34 address spaces, the associated forwarding policies and serves this
35 information to the data plane on demand.
37 Network programmability is achieved by programming forwarding policies
38 such as transparent mobility, service chaining, and traffic engineering
39 in the mapping system; where the data plane elements can fetch these
40 policies on demand as new flows arrive. This chapter describes the LISP
41 Flow Mapping project in OpenDaylight and how it can be used to enable
42 advanced SDN and NFV use cases.
44 LISP data plane Tunnel Routers are available at
45 `LISPmob.org <http://LISPmob.org/>`__ in the open source community on
46 the following platforms:
54 For more details and support for LISP data plane software please visit
55 `the LISPmob web site <http://LISPmob.org/>`__.
57 LISP Flow Mapping Service
58 ~~~~~~~~~~~~~~~~~~~~~~~~~
60 The LISP Flow Mapping service provides LISP Mapping System services.
61 This includes LISP Map-Server and LISP Map-Resolver services to store
62 and serve mapping data to data plane nodes as well as to OpenDaylight
63 applications. Mapping data can include mapping of virtual addresses to
64 physical network address where the virtual nodes are reachable or hosted
65 at. Mapping data can also include a variety of routing policies
66 including traffic engineering and load balancing. To leverage this
67 service, OpenDaylight applications and services can use the northbound
68 REST API to define the mappings and policies in the LISP Mapping
69 Service. Data plane devices capable of LISP control protocol can
70 leverage this service through a southbound LISP plugin. LISP-enabled
71 devices must be configured to use this OpenDaylight service as their Map
72 Server and/or Map Resolver.
74 The southbound LISP plugin supports the LISP control protocol
75 (Map-Register, Map-Request, Map-Reply messages), and can also be used to
76 register mappings in the OpenDaylight mapping service.
78 LISP Flow Mapping Architecture
79 ------------------------------
81 The following figure shows the various LISP Flow Mapping modules.
83 .. figure:: ./images/ODL_lfm_Be_component.jpg
84 :alt: LISP Mapping Service Internal Architecture
86 LISP Mapping Service Internal Architecture
88 A brief description of each module is as follows:
90 - **DAO (Data Access Object):** This layer separates the LISP logic
91 from the database, so that we can separate the map server and map
92 resolver from the specific implementation of the mapping database.
93 Currently we have an implementation of this layer with an in-memory
94 HashMap, but it can be switched to any other key/value store and you
95 only need to implement the ILispDAO interface.
97 - **Map Server:** This module processes the adding or registration of
98 authentication tokens (keys) and mappings. For a detailed
99 specification of LISP Map Server, see
100 `LISP <http://tools.ietf.org/search/rfc6830>`__.
102 - **Map Resolver:** This module receives and processes the mapping
103 lookup queries and provides the mappings to requester. For a detailed
104 specification of LISP Map Server, see
105 `LISP <http://tools.ietf.org/search/rfc6830>`__.
107 - **RPC/RESTCONF:** This is the auto-generated RESTCONF-based
108 northbound API. This module enables defining key-EID associations as
109 well as adding mapping information through the Map Server. Key-EID
110 associations and mappings can also be queried via this API.
112 - **GUI:** This module enables adding and querying the mapping service
113 through a GUI based on ODL DLUX.
115 - **Neutron:** This module implements the OpenDaylight Neutron Service
116 APIs. It provides integration between the LISP service and the
117 OpenDaylight Neutron service, and thus OpenStack.
119 - **Java API:** The API module exposes the Map Server and Map Resolver
120 capabilities via a Java API.
122 - **LISP Proto:** This module includes LISP protocol dependent data
123 types and associated processing.
125 - **In Memory DB:** This module includes the in memory database
126 implementation of the mapping service.
128 - **LISP Southbound Plugin:** This plugin enables data plane devices
129 that support LISP control plane protocol (see
130 `LISP <http://tools.ietf.org/search/rfc6830>`__) to register and
131 query mappings to the LISP Flow Mapping via the LISP control plane
134 Configuring LISP Flow Mapping
135 -----------------------------
137 In order to use the LISP mapping service for registering EID to RLOC
138 mappings from northbound or southbound, keys have to be defined for the
139 EID prefixes first. Once a key is defined for an EID prefix, it can be
140 used to add mappings for that EID prefix multiple times. If the service
141 is going to be used to process Map-Register messages from the southbound
142 LISP plugin, the same key must be used by the data plane device to
143 create the authentication data in the Map-Register messages for the
144 associated EID prefix.
146 The ``etc/custom.properties`` file in the Karaf distribution allows
147 configuration of several OpenDaylight parameters. The LISP service has
148 the following properties that can be adjusted:
150 **lisp.mappingOverwrite** (default: *true*)
151 Configures handling of mapping updates. When set to *true* (default)
152 a mapping update (either through the southbound plugin via a
153 Map-Register message or through a northbound API PUT REST call) the
154 existing RLOC set associated to an EID prefix is overwritten. When
155 set to *false*, the RLOCs of the update are merged to the existing
158 **lisp.smr** (default: *false*)
159 Enables/disables the `Solicit-Map-Request
160 (SMR) <http://tools.ietf.org/html/rfc6830#section-6.6.2>`__
161 functionality. SMR is a method to notify changes in an EID-to-RLOC
162 mapping to "subscribers". The LISP service considers all
163 Map-Request’s source RLOC as a subscriber to the requested EID
164 prefix, and will send an SMR control message to that RLOC if the
167 **lisp.elpPolicy** (default: *default*)
168 Configures how to build a Map-Reply southbound message from a
169 mapping containing an Explicit Locator Path (ELP) RLOC. It is used
170 for compatibility with dataplane devices that don’t understand the
171 ELP LCAF format. The *default* setting doesn’t alter the mapping,
172 returning all RLOCs unmodified. The *both* setting adds a new RLOC
173 to the mapping, with a lower priority than the ELP, that is the next
174 hop in the service chain. To determine the next hop, it searches the
175 source RLOC of the Map-Request in the ELP, and chooses the next hop,
176 if it exists, otherwise it chooses the first hop. The *replace*
177 setting adds a new RLOC using the same algorithm as the *both*
178 setting, but using the origin priority of the ELP RLOC, which is
179 removed from the mapping.
181 **lisp.lookupPolicy** (default: *northboundFirst*)
182 Configures the mapping lookup algorithm. When set to
183 *northboundFirst* mappings programmed through the northbound API
184 will take precedence. If no northbound programmed mappings exist,
185 then the mapping service will return mappings registered through the
186 southbound plugin, if any exists. When set to
187 *northboundAndSouthbound* the mapping programmed by the northbound
188 is returned, updated by the up/down status of these mappings as
189 reported by the southbound (if existing).
191 **lisp.mappingMerge** (default: *false*)
192 Configures the merge policy on the southbound registrations through
193 the LISP SB Plugin. When set to *false*, only the latest mapping
194 registered through the SB plugin is valid in the southbound mapping
195 database, independent of which device it came from. When set to
196 *true*, mappings for the same EID registered by different devices
197 are merged together and a union of the locators is maintained as the
198 valid mapping for that EID.
200 Textual Conventions for LISP Address Formats
201 --------------------------------------------
203 In addition to the more common IPv4, IPv6 and MAC address data types,
204 the LISP control plane supports arbitrary `Address Family
205 Identifiers <http://www.iana.org/assignments/address-family-numbers>`__
206 assigned by IANA, and in addition to those the `LISP Canoncal Address
207 Format (LCAF) <https://tools.ietf.org/html/draft-ietf-lisp-lcaf>`__.
209 The LISP Flow Mapping project in OpenDaylight implements support for
210 many of these different address formats, the full list being summarized
211 in the following table. While some of the address formats have well
212 defined and widely used textual representation, many don’t. It became
213 necessary to define a convention to use for text rendering of all
214 implemented address types in logs, URLs, input fields, etc. The below
215 table lists the supported formats, along with their AFI number and LCAF
216 type, including the prefix used for disambiguation of potential overlap,
219 +------------------+----------+----------+----------+----------------------------------+
220 | Name | AFI | LCAF | Prefix | Text Rendering |
221 +==================+==========+==========+==========+==================================+
222 | **No Address** | 0 | - | no: | No Address Present |
223 +------------------+----------+----------+----------+----------------------------------+
224 | **IPv4 Prefix** | 1 | - | ipv4: | 192.0.2.0/24 |
225 +------------------+----------+----------+----------+----------------------------------+
226 | **IPv6 Prefix** | 2 | - | ipv6: | 2001:db8::/32 |
227 +------------------+----------+----------+----------+----------------------------------+
228 | **MAC Address** | 16389 | - | mac: | 00:00:5E:00:53:00 |
229 +------------------+----------+----------+----------+----------------------------------+
230 | **Distinguished | 17 | - | dn: | stringAsIs |
232 +------------------+----------+----------+----------+----------------------------------+
233 | **AS Number** | 18 | - | as: | AS64500 |
234 +------------------+----------+----------+----------+----------------------------------+
235 | **AFI List** | 16387 | 1 | list: | {192.0.2.1,192.0.2.2,2001:db8::1 |
237 +------------------+----------+----------+----------+----------------------------------+
238 | **Instance ID** | 16387 | 2 | - | [223] 192.0.2.0/24 |
239 +------------------+----------+----------+----------+----------------------------------+
240 | **Application | 16387 | 4 | appdata: | 192.0.2.1!128!17!80-81!6667-7000 |
242 +------------------+----------+----------+----------+----------------------------------+
243 | **Explicit | 16387 | 10 | elp: | {192.0.2.1→192.0.2.2\|lps→192.0. |
244 | Locator Path** | | | | 2.3} |
245 +------------------+----------+----------+----------+----------------------------------+
246 | **Source/Destina | 16387 | 12 | srcdst: | 192.0.2.1/32\|192.0.2.2/32 |
249 +------------------+----------+----------+----------+----------------------------------+
250 | **Key/Value | 16387 | 15 | kv: | 192.0.2.1⇒192.0.2.2 |
251 | Address Pair** | | | | |
252 +------------------+----------+----------+----------+----------------------------------+
253 | **Service Path** | 16387 | N/A | sp: | 42(3) |
254 +------------------+----------+----------+----------+----------------------------------+
256 Table: LISP Address Formats
258 Please note that the forward slash character ``/`` typically separating
259 IPv4 and IPv6 addresses from the mask length is transformed into ``%2f``
265 In this section we will discuss two types of Karaf commands: built-in,
266 and LISP specific. Some built-in commands are quite useful, and are
267 needed for the tutorial, so they will be discussed here. A reference of
268 all LISP specific commands, added by the LISP Flow Mapping project is
269 also included. They are useful mostly for debugging.
271 Useful built-in commands
272 ~~~~~~~~~~~~~~~~~~~~~~~~
275 Lists all available command, with a short description of each.
277 ``help <command_name>``
278 Show detailed help about a specific command.
280 ``feature:list [-i]``
281 Show all locally available features in the Karaf container. The
282 ``-i`` option lists only features that are currently installed. It
283 is possible to use ``| grep`` to filter the output (for all
284 commands, not just this one).
286 ``feature:install <feature_name>``
287 Install feature ``feature_name``.
289 ``log:set <level> <class>``
290 Set the log level for ``class`` to ``level``. The default log level
291 for all classes is INFO. For debugging, or learning about LISP
292 internals it is useful to run
293 ``log:set TRACE org.opendaylight.lispflowmapping`` right after Karaf
297 Outputs the log file to the console, and returns control to the
301 Continuously shows log output, requires ``Ctrl+C`` to return to the
304 LISP specific commands
305 ~~~~~~~~~~~~~~~~~~~~~~
307 The available lisp commands can always be obtained by
308 ``help mappingservice``. Currently they are:
310 ``mappingservice:addkey``
311 Add the default password ``password`` for the IPv4 EID prefix
312 0.0.0.0/0 (all addresses). This is useful when experimenting with
313 southbound devices, and using the REST interface would be combersome
316 ``mappingservice:mappings``
317 Show the list of all mappings stored in the internal non-persistent
318 data store (the DAO), listing the full data structure. The output is
319 not human friendly, but can be used for debugging.
321 LISP Flow Mapping Karaf Features
322 --------------------------------
324 LISP Flow Mapping has the following Karaf features that can be installed
325 from the Karaf console:
327 ``odl-lispflowmapping-msmr``
328 This includes the core features required to use the LISP Flow
329 Mapping Service such as mapping service and the LISP southbound
332 ``odl-lispflowmapping-ui``
333 This includes the GUI module for the LISP Mapping Service.
335 ``odl-lispflowmapping-neutron``
336 This is the experimental Neutron provider module for LISP mapping
342 This section provides a tutorial demonstrating various features in this
345 Creating a LISP overlay
346 ~~~~~~~~~~~~~~~~~~~~~~~
348 This section provides instructions to set up a LISP network of three
349 nodes (one "client" node and two "server" nodes) using LISPmob as data
350 plane LISP nodes and the LISP Flow Mapping project from OpenDaylight as
351 the LISP programmable mapping system for the LISP network.
356 The steps shown below will demonstrate setting up a LISP network between
357 a client and two servers, then performing a failover between the two
363 - **OpenDaylight Boron**
365 - **The Postman Chrome App**: the most convenient way to follow along
366 this tutorial is to use the `Postman Chrome
367 App <https://chrome.google.com/webstore/detail/postman/fhbjgbiflinjbdggehcddcbncdddomop?hl=en>`__
368 to edit and send the requests. The project git repository hosts a
369 collection of the requests that are used in this tutorial in the
370 ``resources/tutorial/Beryllium_Tutorial.json.postman_collection``
371 file. You can import this file to Postman by clicking *Import* at the
372 top, choosing *Download from link* and then entering the following
374 ``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``.
375 Alternatively, you can save the file on your machine, or if you have
376 the repository checked out, you can import from there. You will need
377 to create a new Postman Environment and define some variables within:
378 ``controllerHost`` set to the hostname or IP address of the machine
379 running the ODL instance, and ``restconfPort`` to 8181, if you didn’t
380 modify the default controller settings.
382 - **LISPmob version 0.5.x** The README.md lists the dependencies needed
383 to build it from source.
385 - **A virtualization platform**
390 The three LISP data plane nodes and the LISP mapping system are assumed
391 to be running in Linux virtual machines, which have the ``eth0``
392 interface in NAT mode to allow outside internet access and ``eth1``
393 connected to a host-only network, with the following IP addresses
394 (please adjust configuration files, JSON examples, etc. accordingly if
395 you’re using another addressing scheme):
397 +--------------------------+--------------------------+--------------------------+
398 | Node | Node Type | IP Address |
399 +==========================+==========================+==========================+
400 | **controller** | OpenDaylight | 192.168.16.11 |
401 +--------------------------+--------------------------+--------------------------+
402 | **client** | LISPmob | 192.168.16.30 |
403 +--------------------------+--------------------------+--------------------------+
404 | **server1** | LISPmob | 192.168.16.31 |
405 +--------------------------+--------------------------+--------------------------+
406 | **server2** | LISPmob | 192.168.16.32 |
407 +--------------------------+--------------------------+--------------------------+
408 | **service-node** | LISPmob | 192.168.16.33 |
409 +--------------------------+--------------------------+--------------------------+
411 Table: Nodes in the tutorial
415 While the tutorial uses LISPmob as the data plane, it could be any
416 LISP-enabled hardware or software router (commercial/open source).
421 The below steps use the command line tool cURL to talk to the LISP Flow
422 Mapping RPC REST API. This is so that you can see the actual request
423 URLs and body content on the page.
425 1. Install and run OpenDaylight Boron release on the controller VM.
426 Please follow the general OpenDaylight Boron Installation Guide
427 for this step. Once the OpenDaylight controller is running install
428 the *odl-lispflowmapping-msmr* feature from the Karaf CLI:
432 feature:install odl-lispflowmapping-msmr
434 It takes quite a while to load and initialize all features and their
435 dependencies. It’s worth running the command ``log:tail`` in the
436 Karaf console to see when the log output is winding down, and
437 continue with the tutorial after that.
439 2. Install LISPmob on the **client**, **server1**, **server2**, and
440 **service-node** VMs following the installation instructions `from
442 file <https://github.com/LISPmob/lispmob#software-prerequisites>`__.
444 3. Configure the LISPmob installations from the previous step. Starting
445 from the ``lispd.conf.example`` file in the distribution, set the
446 EID in each ``lispd.conf`` file from the IP address space selected
447 for your virtual/LISP network. In this tutorial the EID of the
448 **client** is set to 1.1.1.1/32, and that of **server1** and
449 **server2** to 2.2.2.2/32.
451 4. Set the RLOC interface to ``eth1`` in each ``lispd.conf`` file. LISP
452 will determine the RLOC (IP address of the corresponding VM) based
455 5. Set the Map-Resolver address to the IP address of the
456 **controller**, and on the **client** the Map-Server too. On
457 **server1** and **server2** set the Map-Server to something else, so
458 that it doesn’t interfere with the mappings on the controller, since
459 we’re going to program them manually.
461 6. Modify the "key" parameter in each ``lispd.conf`` file to a
462 key/password of your choice (*password* in this tutorial).
466 The ``resources/tutorial`` directory in the *stable/boron*
467 branch of the project git repository has the files used in the
469 in <https://git.opendaylight.org/gerrit/gitweb?p=lispflowmapping.git;a=tree;f=resources/tutorial;hb=refs/heads/stable/boron>`__,
470 so you can just copy the files to ``/root/lispd.conf`` on the
471 respective VMs. You will also find the JSON files referenced
472 below in the same directory.
474 7. Define a key and EID prefix association in OpenDaylight using the
475 RPC REST API for the **client** EID (1.1.1.1/32) to allow
476 registration from the southbound. Since the mappings for the server
477 EID will be configured from the REST API, no such association is
478 necessary. Run the below command on the **controller** (or any
479 machine that can reach **controller**, by replacing *localhost* with
480 the IP address of **controller**).
484 curl -u "admin":"admin" -H "Content-type: application/json" -X POST \
485 http://localhost:8181/restconf/operations/odl-mappingservice:add-key \
488 where the content of the *add-key.json* file is the following:
495 "address-type": "ietf-lisp-address-types:ipv4-prefix-afi",
496 "ipv4-prefix": "1.1.1.1/32"
499 "key-string": "password",
505 8. Verify that the key is added properly by requesting the following
510 curl -u "admin":"admin" -H "Content-type: application/json" -X POST \
511 http://localhost:8181/restconf/operations/odl-mappingservice:get-key \
514 where the content of the *get1.json* file can be derived from the
515 *add-key.json* file by removing the *mapping-authkey* field. The
516 output the above invocation should look like this:
520 {"output":{"mapping-authkey":{"key-type":1,"key-string":"password"}}}
522 9. Run the ``lispd`` LISPmob daemon on all VMs:
526 lispd -f /root/lispd.conf
528 10. The **client** LISPmob node should now register its EID-to-RLOC
529 mapping in OpenDaylight. To verify you can lookup the corresponding
530 EIDs via the REST API
534 curl -u "admin":"admin" -H "Content-type: application/json" -X POST \
535 http://localhost:8181/restconf/operations/odl-mappingservice:get-mapping \
538 An alternative way for retrieving mappings from ODL using the
539 southbound interface is using the
540 ```lig`` <https://github.com/davidmeyer/lig>`__ open source tool.
542 11. Register the EID-to-RLOC mapping of the server EID 2.2.2.2/32 to the
543 controller, pointing to **server1** and **server2** with a higher
544 priority for **server1**
548 curl -u "admin":"admin" -H "Content-type: application/json" -X POST \
549 http://localhost:8181/restconf/operations/odl-mappingservice:add-mapping \
552 where the *mapping.json* file looks like this:
560 "action": "NoAction",
561 "authoritative": true,
563 "address-type": "ietf-lisp-address-types:ipv4-prefix-afi",
564 "ipv4-prefix": "2.2.2.2/32"
568 "locator-id": "server1",
571 "multicastPriority": 255,
572 "multicastWeight": 0,
573 "localLocator": true,
577 "address-type": "ietf-lisp-address-types:ipv4-afi",
578 "ipv4": "192.168.16.31"
582 "locator-id": "server2",
585 "multicastPriority": 255,
586 "multicastWeight": 0,
587 "localLocator": true,
591 "address-type": "ietf-lisp-address-types:ipv4-afi",
592 "ipv4": "192.168.16.32"
600 Here the priority of the second RLOC (192.168.16.32 - **server2**)
601 is 2, a higher numeric value than the priority of 192.168.16.31,
602 which is 1. This policy is saying that **server1** is preferred to
603 **server2** for reaching EID 2.2.2.2/32. Note that lower priority
604 value has higher preference in LISP.
606 12. Verify the correct registration of the 2.2.2.2/32 EID:
610 curl -u "admin":"admin" -H "Content-type: application/json" -X POST \
611 http://localhost:8181/restconf/operations/odl-mappingservice:get-mapping \
614 where *get2.json* can be derived from *get1.json* by changing the
615 content of the *Ipv4Address* field from *1.1.1.1* to *2.2.2.2*.
617 13. Now the LISP network is up. To verify, log into the **client** VM
618 and ping the server EID:
624 14. Let’s test fail-over now. Suppose you had a service on **server1**
625 which became unavailable, but **server1** itself is still reachable.
626 LISP will not automatically fail over, even if the mapping for
627 2.2.2.2/32 has two locators, since both locators are still reachable
628 and uses the one with the higher priority (lowest priority value).
629 To force a failover, we need to set the priority of **server2** to a
630 lower value. Using the file mapping.json above, swap the priority
631 values between the two locators (lines 14 and 28 in *mapping.json*)
632 and repeat the request from step 11. You can also repeat step 12 to
633 see if the mapping is correctly registered. If you leave the ping
634 on, and monitor the traffic using wireshark, you can see that the
635 ping traffic to 2.2.2.2 will be diverted from the **server1** RLOC
636 to the **server2** RLOC.
638 With the default OpenDaylight configuration the failover should be
639 near instantaneous (we observed 3 lost pings in the worst case),
640 because of the LISP `Solicit-Map-Request (SMR)
641 mechanism <http://tools.ietf.org/html/rfc6830#section-6.6.2>`__ that
642 can ask a LISP data plane element to update its mapping for a
643 certain EID (enabled by default). It is controlled by the
644 ``lisp.smr`` variable in ``etc/custom.porperties``. When enabled,
645 any mapping change from the RPC interface will trigger an SMR packet
646 to all data plane elements that have requested the mapping in the
647 last 24 hours (this value was chosen because it’s the default TTL of
648 Cisco IOS xTR mapping registrations). If disabled, ITRs keep their
649 mappings until the TTL specified in the Map-Reply expires.
651 15. To add a service chain into the path from the client to the server,
652 we can use an Explicit Locator Path, specifying the **service-node**
653 as the first hop and **server1** (or **server2**) as the second hop.
654 The following will achieve that:
658 curl -u "admin":"admin" -H "Content-type: application/json" -X POST \
659 http://localhost:8181/restconf/operations/odl-mappingservice:add-mapping \
662 where the *elp.json* file is as follows:
670 "action": "NoAction",
671 "authoritative": true,
673 "address-type": "ietf-lisp-address-types:ipv4-prefix-afi",
674 "ipv4-prefix": "2.2.2.2/32"
681 "multicastPriority": 255,
682 "multicastWeight": 0,
683 "localLocator": true,
687 "address-type": "ietf-lisp-address-types:explicit-locator-path-lcaf",
688 "explicit-locator-path": {
691 "hop-id": "service-node",
692 "address": "192.168.16.33",
697 "address": "192.168.16.31",
709 After the mapping for 2.2.2.2/32 is updated with the above, the ICMP
710 traffic from **client** to **server1** will flow through the
711 **service-node**. You can confirm this in the LISPmob logs, or by
712 sniffing the traffic on either the **service-node** or **server1**.
713 Note that service chains are unidirectional, so unless another ELP
714 mapping is added for the return traffic, packets will go from
715 **server1** to **client** directly.
717 16. Suppose the **service-node** is actually a firewall, and traffic is
718 diverted there to support access control lists (ACLs). In this
719 tutorial that can be emulated by using ``iptables`` firewall rules
720 in the **service-node** VM. To deny traffic on the service chain
721 defined above, the following rule can be added:
725 iptables -A OUTPUT --dst 192.168.16.31 -j DROP
727 The ping from the **client** should now have stopped.
729 In this case the ACL is done on the destination RLOC. There is an
730 effort underway in the LISPmob community to allow filtering on EIDs,
731 which is the more logical place to apply ACLs.
733 17. To delete the rule and restore connectivity on the service chain,
734 delete the ACL by issuing the following command:
738 iptables -D OUTPUT --dst 192.168.16.31 -j DROP
740 which should restore connectivity.
742 LISP Flow Mapping Support
743 -------------------------
745 For support the lispflowmapping project can be reached by emailing the
746 developer mailing list: lispflowmapping-dev@lists.opendaylight.org or on
747 the #opendaylight-lispflowmapping IRC channel on irc.freenode.net.
749 Additional information is also available on the `Lisp Flow Mapping
750 wiki <https://wiki.opendaylight.org/view/OpenDaylight_Lisp_Flow_Mapping:Main>`__
752 Clustering in LISP Flow Mapping
753 -------------------------------
755 Documentation regarding setting up a 3-node OpenDaylight cluster is
756 described at following `odl wiki
757 page <https://wiki.opendaylight.org/view/Running_and_testing_an_OpenDaylight_Cluster#Three-node_cluster>`__.
759 To turn on clustering in LISP Flow Mapping it is necessary:
761 - run script **deploy.py** script. This script is in
762 `integration-test <https://git.opendaylight.org/gerrit/integration/test>`__
763 project placed at *tools/clustering/cluster-deployer/deploy.py*. A
764 whole deploy.py command can looks like:
768 <div class="informalexample">
770 | {path\_to\_integration\_test\_project}/tools/clustering/cluster-deployer/**deploy.py**
771 | --**distribution** {path\_to\_distribution\_in\_zip\_format}
772 | --**rootdir** {dir\_at\_remote\_host\_where\_copy\_odl\_distribution}
773 | --**hosts** {ip1},{ip2},{ip3}
775 | --**template** lispflowmapping
777 | --**user** {user\_name\_of\_remote\_hosts}
778 | --**password** {password\_to\_remote\_hosts}
784 | Running this script will cause that specified **distribution** to be
785 deployed to remote **hosts** specified through their IP adresses with
786 using credentials (**user** and **password**). The distribution will
787 be copied to specified **rootdir**. As part of the deployment, a
788 **template** which contains a set of controller files which are
789 different from standard ones. In this case it is specified in
790 | *{path\_to\_integration\_test\_project}/tools/clustering/cluster-deployer/lispflowmapping*
792 | Lispflowmapping templates are part of integration-test project. There
793 are 5 template files:
797 - jolokia.xml.template
799 - module-shards.conf.template
801 - modules.conf.template
803 - org.apache.karaf.features.cfg.template
805 After copying the distribution, it is unzipped and started on all of
806 specified **hosts** in cluster aware manner.
811 It is necessary to have:
813 - **unzip** program installed on all of the host
815 - set all remote hosts /etc/sudoers files to not **requiretty** (should
816 only matter on debian hosts)