]>
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 | ||
393231b2 LJ |
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. | |
a6ae068b LJ |
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 | |
eb812488 LJ |
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. | |
a6ae068b LJ |
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 | |
ec9f40dc | 38 | MAC address 02:00:00:00:00:00. This address has all bits set to 0, except the |
a6ae068b LJ |
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 | |
393231b2 | 63 | ovs-vsctl add-port br0 lisp0 -- set Interface lisp0 type=lisp options:remote_ip=flow options:key=flow |
a6ae068b | 64 | |
eb812488 LJ |
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: | |
a6ae068b LJ |
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 | |
393231b2 | 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 |
a6ae068b | 74 | priority=0,action=NORMAL |
393231b2 | 75 | |
eb812488 LJ |
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. |