Setting tag sliver-openvswitch-2.2.90-1

[sliver-openvswitch.git] / README-lisp

diff --git a/README-lisp b/README-lisp
index 7c9071a..f1e1172 100644 (file)
--- a/README-lisp
+++ b/README-lisp
@@ -6,11 +6,12 @@ not carry Ethernet headers, and ARP requests shouldn't be sent over the
 tunnel.  Because of this, there are some additional steps required for setting
 up LISP tunnels in Open vSwitch, until support for L3 tunnels will improve.
 
-This guide assumes a point-to-point tunnel between two VMs connected to OVS
-bridges on different hypervisors connected via IPv4.  Of course, more than one
-VM may be connected to any of the hypervisors, using the same LISP tunnel, and
-a hypervisor may be connected to several hypervisors over different LISP
-tunnels.
+This guide assumes tunneling between two VMs connected to OVS bridges on
+different hypervisors reachable over IPv4.  Of course, more than one VM may be
+connected to any of the hypervisors, and a hypervisor may communicate with
+several different hypervisors over the same lisp tunneling interface.  A LISP
+"map-cache" can be implemented using flows, see example at the bottom of this
+file.
 
 There are several scenarios:
 
@@ -29,11 +30,12 @@ VMs.
 In case 2) the VMs expect ARP replies from each other, but this is not
 possible over a layer 3 tunnel.  One solution is to have static MAC address
 entries preconfigured on the VMs (e.g., `arp -f /etc/ethers` on startup on
-Unix based VMs), or have the hypervisor do proxy ARP.
+Unix based VMs), or have the hypervisor do proxy ARP.  In this scenario, the
+eth0 interfaces need not be added to the br0 bridge in the examples below.
 
 On the receiving side, the packet arrives without the original MAC header.
 The LISP tunneling code attaches a header with harcoded source and destination
-MAC addres 02:00:00:00:00:00.  This address has all bits set to 0, except the
+MAC address 02:00:00:00:00:00.  This address has all bits set to 0, except the
 locally administered bit, in order to avoid potential collisions with existing
 allocations.  In order for packets to reach their intended destination, the
 destination MAC address needs to be rewritten.  This can be done using the
@@ -58,11 +60,22 @@ bridge instance, and become numbered 1, 2, and 3 respectively:
     ovs-vsctl add-br br0
     ovs-vsctl add-port br0 tap0
     ovs-vsctl add-port br0 eth0
-    ovs-vsctl add-port br0 lisp0 -- set Interface lisp0 type=lisp options:remote_ip=<OVSx_IP>
+    ovs-vsctl add-port br0 lisp0 -- set Interface lisp0 type=lisp options:remote_ip=flow options:key=flow
 
-Flows on br0 are configured as follows:
+The last command sets up flow based tunneling on the lisp0 interface.  From
+the LISP point of view, this is like having the Tunnel Router map cache
+implemented as flow rules.
+
+Flows on br0 should be configured as follows:
 
     priority=3,dl_dst=02:00:00:00:00:00,action=mod_dl_dst:<VMx_MAC>,output:1
     priority=2,in_port=1,dl_type=0x0806,action=NORMAL
-    priority=1,in_port=1,dl_type=0x0800,vlan_tci=0,nw_src=<EID_prefix>,action=output:3
+    priority=1,in_port=1,dl_type=0x0800,vlan_tci=0,nw_src=<EID_prefix>,action=set_field:<OVSx_IP>->tun_dst,output:3
     priority=0,action=NORMAL
+
+The third rule is like a map cache entry:  the <EID_prefix> specified by the
+nw_src match field is mapped to the RLOC <OVSx_IP>, which is set as the tunnel
+destination for this particular flow.
+
+Optionally, if you want to use Instance ID in a flow, you can add
+"set_tunnel:<IID>" to the action list.