mirror of
https://github.com/openvswitch/ovs
synced 2025-10-13 14:07:02 +00:00
69 lines
3.2 KiB
Plaintext
69 lines
3.2 KiB
Plaintext
|
Using LISP tunneling
|
||
|
|
====================
|
||
|
|
|
||
|
|
LISP is a layer 3 tunneling mechanism, meaning that encapsulated packets do
|
||
|
|
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.
|
||
|
|
|
||
|
|
There are several scenarios:
|
||
|
|
|
||
|
|
1) the VMs have IP addresses in the same subnet and the hypervisors are also
|
||
|
|
in a single subnet (although one different from the VM's);
|
||
|
|
2) the VMs have IP addresses in the same subnet but the hypervisors are
|
||
|
|
separated by a router;
|
||
|
|
3) the VMs are in different subnets.
|
||
|
|
|
||
|
|
In cases 1) and 3) ARP resolution can work as normal: ARP traffic is
|
||
|
|
configured not to go through the LISP tunnel. For case 1) ARP is able to
|
||
|
|
reach the other VM, if both OVS instances default to MAC address learning.
|
||
|
|
Case 3) requires the hypervisor be configured as the default router for the
|
||
|
|
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.
|
||
|
|
|
||
|
|
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
|
||
|
|
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
|
||
|
|
flow table.
|
||
|
|
|
||
|
|
See below for an example setup, and the associated flow rules to enable LISP
|
||
|
|
tunneling.
|
||
|
|
|
||
|
|
+---+ +---+
|
||
|
|
|VM1| |VM2|
|
||
|
|
+---+ +---+
|
||
|
|
| |
|
||
|
|
+--[tap0]--+ +--[tap0]---+
|
||
|
|
| | | |
|
||
|
|
[lisp0] OVS1 [eth0]-----------------[eth0] OVS2 [lisp0]
|
||
|
|
| | | |
|
||
|
|
+----------+ +-----------+
|
||
|
|
|
||
|
|
On each hypervisor, interfaces tap0, eth0, and lisp0 are added to a single
|
||
|
|
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>
|
||
|
|
|
||
|
|
Flows on br0 are 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=0,action=NORMAL
|