LISP is a three-layer tunneling mechanism, which means that packets encapsulated with Ethernet header does not carry the second floor, and should not send ARP request packets through the tunnel. Thus, LISP tunnel provided Open vSwitch requires extra steps, until the support L3 tunnel is improved.
This guide assumes that LISP tunnel located between two VM virtual machine, the two virtual machines connected to a different hypervisor of OVS bridge between them reachable by IPv4 addresses. Of course, more than one virtual machine may be connected to any hypervisor, hypervisor and hypervisor may be a plurality of different interface for communicating with the tunnel via a LISP. LISP "map cache" can be used to achieve flow, see the last example in this article.
The following situations:
- IP address of the virtual machines on the same subnet, hypervisors also (and virtual machine on a different subnet) single subnet;
- IP address of the virtual machines on the same subnet, but hypervisors are separated by a router (not in the same subnet);
- Virtual machine in a different subnet.
In case 1) and 3), ARP resolve to work properly: ARP traffic is configured to not go through the tunnel LISP. For case 1) ARP can reach another VM, if two instances OVS MAC address learning is enabled by default. For case 3) requires hypervisor configured as the default router of the virtual machine.
case 2) the virtual machine expect the other side of the ARP response, but in the three networks this is not possible. One solution is to pre-configure the VM static MAC address entry (e.g., executed at startup Unix-based VM arp -f /etc/ethers). Or let the hypervisor to do proxy ARP. In this case, eth0 in the following example, it is unnecessary to add br0 bridge.
At the receiving end, without the original MAC header packet arrives complement. Tunnel LISP code adds a hard-coded addresses of source and destination MAC 02:00:00:00:00:00header. In addition to the local administration bit, all bits other bits of this address are set to 0, in order to avoid potential conflicts with existing MAC address. To make the data packet to reach its intended destination, the destination MAC address needs to be rewritten. This can be done using a flow meter.
See the following example settings, and enable the required flow association rules LISP tunnel.
Diagram
+---+ +---+
|VM1| |VM2|
+---+ +---+
| |
+--[tap0]--+ +--[tap0]---+
| | | |
[lisp0] OVS1 [eth0]-----------------[eth0] OVS2 [lisp0]
| | | |
+----------+ +-----------+
In each of the hypervisor, the interface tap0, eth0 lisp0 and added to a separate bridge example, port number are changed to 1,2,3.
$ 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=flow options:key=flow
The last command is provided on lisp0 flow-based interface of the tunnel. From the point of view of LISP, it's like Tunnel Router map cache is implemented as flow rules.
Br0 bridge stream 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=set_field:<OVSx_IP>->tun_dst,output:3
priority=0,action=NORMAL
The third rule is similar to map cache entries: the nw_srcmatching field specifies the <EID_prefix>mapping to the RLOC <OVSx_IP>, this field is set for this particular flow tunnel destination.
Alternatively, if you are using the instance ID in the stream may be added to the list of actions set_tunnel:<IID>.