projects / mirror_ovs.git / blame
| Commit | Line | Data |
|---|---|---|
| a6ae068b LJ |
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 a point-to-point tunnel between two VMs connected to OVS | |
| 10 | bridges on different hypervisors connected via IPv4. Of course, more than one | |
| 11 | VM may be connected to any of the hypervisors, using the same LISP tunnel, and | |
| 12 | a hypervisor may be connected to several hypervisors over different LISP | |
| 13 | tunnels. | |
| 14 | ||
| 15 | There are several scenarios: | |
| 16 | ||
| 17 | 1) the VMs have IP addresses in the same subnet and the hypervisors are also | |
| 18 | in a single subnet (although one different from the VM's); | |
| 19 | 2) the VMs have IP addresses in the same subnet but the hypervisors are | |
| 20 | separated by a router; | |
| 21 | 3) the VMs are in different subnets. | |
| 22 | ||
| 23 | In cases 1) and 3) ARP resolution can work as normal: ARP traffic is | |
| 24 | configured not to go through the LISP tunnel. For case 1) ARP is able to | |
| 25 | reach the other VM, if both OVS instances default to MAC address learning. | |
| 26 | Case 3) requires the hypervisor be configured as the default router for the | |
| 27 | VMs. | |
| 28 | ||
| 29 | In case 2) the VMs expect ARP replies from each other, but this is not | |
| 30 | possible over a layer 3 tunnel. One solution is to have static MAC address | |
| 31 | entries preconfigured on the VMs (e.g., `arp -f /etc/ethers` on startup on | |
| 32 | Unix based VMs), or have the hypervisor do proxy ARP. | |
| 33 | ||
| 34 | On the receiving side, the packet arrives without the original MAC header. | |
| 35 | The LISP tunneling code attaches a header with harcoded source and destination | |
| 36 | MAC addres 02:00:00:00:00:00. This address has all bits set to 0, except the | |
| 37 | locally administered bit, in order to avoid potential collisions with existing | |
| 38 | allocations. In order for packets to reach their intended destination, the | |
| 39 | destination MAC address needs to be rewritten. This can be done using the | |
| 40 | flow table. | |
| 41 | ||
| 42 | See below for an example setup, and the associated flow rules to enable LISP | |
| 43 | tunneling. | |
| 44 | ||
| 45 | +---+ +---+ | |
| 46 | |VM1| |VM2| | |
| 47 | +---+ +---+ | |
| 48 | | | | |
| 49 | +--[tap0]--+ +--[tap0]---+ | |
| 50 | | | | | | |
| 51 | [lisp0] OVS1 [eth0]-----------------[eth0] OVS2 [lisp0] | |
| 52 | | | | | | |
| 53 | +----------+ +-----------+ | |
| 54 | ||
| 55 | On each hypervisor, interfaces tap0, eth0, and lisp0 are added to a single | |
| 56 | bridge instance, and become numbered 1, 2, and 3 respectively: | |
| 57 | ||
| 58 | ovs-vsctl add-br br0 | |
| 59 | ovs-vsctl add-port br0 tap0 | |
| 60 | ovs-vsctl add-port br0 eth0 | |
| 61 | ovs-vsctl add-port br0 lisp0 -- set Interface lisp0 type=lisp options:remote_ip=<OVSx_IP> | |
| 62 | ||
| 63 | Flows on br0 are configured as follows: | |
| 64 | ||
| 65 | priority=3,dl_dst=02:00:00:00:00:00,action=mod_dl_dst:<VMx_MAC>,output:1 | |
| 66 | priority=2,in_port=1,dl_type=0x0806,action=NORMAL | |
| 67 | priority=1,in_port=1,dl_type=0x0800,vlan_tci=0,nw_src=<EID_prefix>,action=output:3 | |
| 68 | priority=0,action=NORMAL |