README-lisp.md

   1 Using LISP tunneling
   2 ====================
   3
   4 LISP is a layer 3 tunneling mechanism, meaning that encapsulated packets do
   5 not carry Ethernet headers, and ARP requests shouldn't be sent over the
   6 tunnel.  Because of this, there are some additional steps required for setting
   7 up LISP tunnels in Open vSwitch, until support for L3 tunnels will improve.
   8
   9 This guide assumes tunneling between two VMs connected to OVS bridges on
  10 different hypervisors reachable over IPv4.  Of course, more than one VM may be
  11 connected to any of the hypervisors, and a hypervisor may communicate with
  12 several different hypervisors over the same lisp tunneling interface.  A LISP
  13 "map-cache" can be implemented using flows, see example at the bottom of this
  14 file.
  15
  16 There are several scenarios:
  17
  18   1) the VMs have IP addresses in the same subnet and the hypervisors are also
  19      in a single subnet (although one different from the VM's);
  20   2) the VMs have IP addresses in the same subnet but the hypervisors are
  21      separated by a router;
  22   3) the VMs are in different subnets.
  23
  24 In cases 1) and 3) ARP resolution can work as normal: ARP traffic is
  25 configured not to go through the LISP tunnel.  For case 1) ARP is able to
  26 reach the other VM, if both OVS instances default to MAC address learning.
  27 Case 3) requires the hypervisor be configured as the default router for the
  28 VMs.
  29
  30 In case 2) the VMs expect ARP replies from each other, but this is not
  31 possible over a layer 3 tunnel.  One solution is to have static MAC address
  32 entries preconfigured on the VMs (e.g., `arp -f /etc/ethers` on startup on
  33 Unix based VMs), or have the hypervisor do proxy ARP.  In this scenario, the
  34 eth0 interfaces need not be added to the br0 bridge in the examples below.
  35
  36 On the receiving side, the packet arrives without the original MAC header.
  37 The LISP tunneling code attaches a header with harcoded source and destination
  38 MAC address 02:00:00:00:00:00.  This address has all bits set to 0, except the
  39 locally administered bit, in order to avoid potential collisions with existing
  40 allocations.  In order for packets to reach their intended destination, the
  41 destination MAC address needs to be rewritten.  This can be done using the
  42 flow table.
  43
  44 See below for an example setup, and the associated flow rules to enable LISP
  45 tunneling.
  46
  47                +---+                               +---+
  48                |VM1|                               |VM2|
  49                +---+                               +---+
  50                  |                                   |
  51             +--[tap0]--+                       +--[tap0]---+
  52             |          |                       |           |
  53         [lisp0] OVS1 [eth0]-----------------[eth0] OVS2 [lisp0]
  54             |          |                       |           |
  55             +----------+                       +-----------+
  56
  57 On each hypervisor, interfaces tap0, eth0, and lisp0 are added to a single
  58 bridge instance, and become numbered 1, 2, and 3 respectively:
  59
  60     ovs-vsctl add-br br0
  61     ovs-vsctl add-port br0 tap0
  62     ovs-vsctl add-port br0 eth0
  63     ovs-vsctl add-port br0 lisp0 -- set Interface lisp0 type=lisp options:remote_ip=flow options:key=flow
  64
  65 The last command sets up flow based tunneling on the lisp0 interface.  From
  66 the LISP point of view, this is like having the Tunnel Router map cache
  67 implemented as flow rules.
  68
  69 Flows on br0 should be configured as follows:
  70
  71     priority=3,dl_dst=02:00:00:00:00:00,action=mod_dl_dst:<VMx_MAC>,output:1
  72     priority=2,in_port=1,dl_type=0x0806,action=NORMAL
  73     priority=1,in_port=1,dl_type=0x0800,vlan_tci=0,nw_src=<EID_prefix>,action=set_field:<OVSx_IP>->tun_dst,output:3
  74     priority=0,action=NORMAL
  75
  76 The third rule is like a map cache entry:  the <EID_prefix> specified by the
  77 nw_src match field is mapped to the RLOC <OVSx_IP>, which is set as the tunnel
  78 destination for this particular flow.
  79
  80 Optionally, if you want to use Instance ID in a flow, you can add
  81 "set_tunnel:<IID>" to the action list.