Skip to content

Commit

Permalink
README-lisp: improve LISP documentation
Browse files Browse the repository at this point in the history
People familiar with LISP are used to the concept of a mapping cache in
a LISP Tunnel Router.  Explain how that concept maps to OVS flow rules.
Additionally, mention that eth0 need not be added in all example
scenarios.

Signed-off-by: Lorand Jakab <[email protected]>
Signed-off-by: Ben Pfaff <[email protected]>
  • Loading branch information
ljakab authored and blp committed Mar 11, 2014
1 parent f35c2d6 commit eb81248
Showing 1 changed file with 13 additions and 4 deletions.
17 changes: 13 additions & 4 deletions README-lisp
Original file line number Diff line number Diff line change
Expand Up @@ -30,7 +30,8 @@ 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.
Unix based VMs), or have the hypervisor do proxy ARP. In this scenario, the
eth0 interfaces need not be added to the br0 bridge in the examples below.

On the receiving side, the packet arrives without the original MAC header.
The LISP tunneling code attaches a header with harcoded source and destination
Expand Down Expand Up @@ -61,12 +62,20 @@ bridge instance, and become numbered 1, 2, and 3 respectively:
ovs-vsctl add-port br0 eth0
ovs-vsctl add-port br0 lisp0 -- set Interface lisp0 type=lisp options:remote_ip=flow options:key=flow

Flows on br0 are configured as follows:
The last command sets up flow based tunneling on the lisp0 interface. From
the LISP point of view, this is like having the Tunnel Router map cache
implemented as flow rules.

Flows on br0 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

Optionally, if you want to use Instance ID in a flow, you can set it with
"action=set_tunnel:<IID>".
The third rule is like a map cache entry: the <EID_prefix> specified by the
nw_src match field is mapped to the RLOC <OVSx_IP>, which is set as the tunnel
destination for this particular flow.

Optionally, if you want to use Instance ID in a flow, you can add
"set_tunnel:<IID>" to the action list.

0 comments on commit eb81248

Please sign in to comment.