LISP是一个三层隧道机制,这意味着封装的报文不会携带二层的以太网头部,并且不应该通过隧道发送ARP请求报文。因此,在Open vSwitch中设置LISP隧道需要一些额外的步骤,直到L3隧道的支持得到改进。
本指南假设LISP隧道位于两个VM虚拟机之间,这两个虚拟机连接在不同hypervisor的OVS网桥上,它们之间通过IPv4地址可达。当然,可能不止一个虚拟机连接到任意hypervisor,并且hypervisor可以与多个不同的hypervisor通过同一个LISP隧道接口通信。LISP "map cache"可以使用流实现,请参见本文最后的示例。
有以下几种情况:
在case 1)和 3)中,ARP解析可以正常工作:ARP流量配置为不经过LISP隧道。对于case 1)ARP能够到达另一个VM,如果两个OVS实例都默认开启了MAC地址学习。对于case 3)要求hypervisor配置为虚拟机的默认路由器。
case 2) 虚拟机期望对方的ARP响应,但在三次网络上这是不可能的。一种解决方案是在VM中预配置静态MAC地址条目(例如,在基于Unix的VM启动时执行arp -f /etc/ethers
)。或者让hypervisor做ARP代理。在此情况下,eth0在下面的示例中,不需要添加到br0网桥。
在接收端,数据包到达时没有原始的MAC头补。LISP隧道的代码添加了一个硬编码源和目标MAC地址为02:00:00:00:00:00
的头部。除了本地管理的位,此地址的所有位其它位都设置为0,以避免与现有MAC地址的潜在冲突。为了使数据包到达其预期目的地,需要重写目标MAC地址。这可以使用流表来完成。
请参阅下面的示例设置,以及启用LISP隧道的所需的关联流规则。
Diagram
+---+ +---+
|VM1| |VM2|
+---+ +---+
| |
+--[tap0]--+ +--[tap0]---+
| | | |
[lisp0] OVS1 [eth0]-----------------[eth0] OVS2 [lisp0]
| | | |
+----------+ +-----------+
在每一个hypervisor,接口tap0、eth0和lisp0添加到一个单独的网桥实例,分别变为编号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
最后一个命令在lisp0接口上设置基于流的隧道。从LISP的角度来看,这就像Tunnel Router map cache实现为流规则。
网桥br0上的流应配置如下:
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
第三个规则类似于map cache 条目:由nw_src
匹配字段指定的<EID_prefix>
映射到RLOC <OVSx_IP>
,该字段设置为此特定流的隧道目的地。
或者,如果要在流中使用实例ID,可以在动作列表中添加set_tunnel:<IID>
。