Neutron 理解 (1): Neutron 所实现的虚拟化网络
Neutron 理解 (2): 使用 Open vSwitch + VLAN 组网
Neutron 理解 (3): Open vSwitch + GRE/VxLAN 组网
OVS bridge 有两种模式:“normal” 和 “flow”。“normal” 模式的 bridge 同普通的 Linux 桥,而 “flow” 模式的 bridge 是根据其流表(flow tables) 来进行转发的。Neutron 使用两种 OVS bridge:br-int 和 br-tun。其中,br-int 是一个 “normal” 模式的虚拟网桥,而 br-tun 是 “flow” 模式的,它比 br-int 复杂得多。
1. 基础知识
1.1 OpenFlow 结构、流表和数据包处理
下面一图是 Open vSwitch 中流表的结构。二图这个流程图详细描述了数据包流通过一个 OpenFlow 交换机的过程。
更详细的描述请参见这里。
1.2 ARP Proxy
Proxy ARP 就是通过一个主机(通常是Router)来作为指定的设备对另一个设备作出 ARP 的请求进行应答。
举个例子:主机A,IP地址是192.168.0.11/24;主机B,IP地址是192.168.1.22/24。主机A和主机B通过路由器R相连接,并且路由器R启用了Proxy ARP,并配置有路由。网络拓扑如下:
eth0 eth0 eth1 eth0
A------------------------Router R----------------------B
192.168.0.11/24 192.168.0.0/24 eth0 192.168.1.22/24
192.168.1.0/24 eth1
这样做的好处就是,主机A上不需要设置任何默认网关或路由策略,不管路由器R的IP地址怎么变化,主机A都能通过路由器B到达主机B,也就是实现了所谓的透明代理。相反,若主机A上设置有默认网关或路由策略时,当主机A向192.168.1.22发送报文,首先要查找路由表,而主机A所在的网段是192.168.0.0/24,主机B所在网段是192.168.1.0/24,主机A只能通过默认网关将报文发送出去,这样代理ARP也就失去了作用。
优点: 最主要的一个优点就是能够在不影响其他router的路由表的情况下在网络上添加一个新的router,这样使得子网的变化对主机是透明的。 proxy ARP应该使用在主机没有配置默认网关或没有任何路由策略的网络上
缺点:
1.增加了某一网段上 ARP 流量
2.主机需要更大的 ARP table 来处理IP地址到MAC地址的映射
3.安全问题,比如 ARP 欺骗(spoofing)
4.不会为不使用 ARP 来解析地址的网络工作
5.不能够概括和推广网络拓扑
2. 不使用 ARP Responder 和 DVR 时 br-tun 中的流表(flow tables)
OpenStack 中,Neutron 作为 OVS 的 Controller,向 OVS 发出管理 tunnel port 的指令,以及提供流表。
2.1 流表分析
Neutron 定义了多种流表。以下面的配置(配置了 GRE 和 VXLAN 两种 tunnel types)为例:
1(patch-int): addr:a6:d4:dd:37:00:52
2(vxlan-0a000127): addr:36:ec:de:b4:b9:6b {in_key=flow, local_ip="10.0.1.31", out_key=flow, remote_ip="10.0.1.39"} 计算节点2
3(vxlan-0a000115): addr:4a:c8:21:3c:3f:f1 {in_key=flow, local_ip="10.0.1.31", out_key=flow, remote_ip="10.0.1.21"} 网络节点
4(gre-0a000115): addr:4a:8b:0f:9d:59:52 {in_key=flow, local_ip="10.0.1.31", out_key=flow, remote_ip="10.0.1.21"} 网络节点
5(gre-0a000127): addr:aa:58:6d:0a:f7:6a {in_key=flow, local_ip="10.0.1.31", out_key=flow, remote_ip="10.0.1.39"} 计算节点2
其中,10.0.1.31 是计算节点1, 10.0.1.21 是网络节点, 10.0.1.39 是计算节点2。
计算节点1 上 ML2 Agent 启动后的 br-tun 的 flows:
来个图简单些:
其中比较有意思的是:
(1)为什么从 VXLAN 过来的流量都被丢弃了,最后发出去也用的是 GRE 端口。看来同时有 GRE 和 VXLAN 隧道的话,OVS 只会选择 GRE。具体原因待查。
(2)MAC 地址学习:Table 10 会将学习到的规则(Local VLAN id + Src MAC Addr => IN_Port)放到 table 20。当表格20 发现一个单播地址是已知的时候,直接从一个特定的 GRE 端口发出;未知的话,视同组播地址从所有 GRE 端口发出。
2.2 MAC 地址学习
学习规则:
table=20,hard_timeout=300,priority=1,NXM_OF_VLAN_TCI[0..11],NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],load:0->NXM_OF_VLAN_TCI[],load:NXM_NX_TUN_ID[]->NXM_NX_TUN_ID[],output:NXM_OF_IN_PORT[]
这语法不是很好理解,这里有详细解释。
- table=20:修改 table 20。这是个 MAC 学习流表。
- hard_timeout:该 flow 的过期时间。
- NXM_OF_VLAN_TCI[0..11] :记录 vlan tag,所以学习结果中有 dl_vlan=1
- NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[] :将 mac source address 记录,所以结果中有 dl_dst=fa:16:3e:7e:ab:cc
- load:0->NXM_OF_VLAN_TCI[]:在发送出去的时候,vlan tag设为0,所以结