场景&＃xff08;一个租户&＃xff0c;两个网络&＃xff0c;一个路由&＃xff0c;内部网络使用GRE&＃xff0c;Libvirt VIF Driver使用LibvirtHybridOVSBridgeDriver&＃xff09;&＃xff1a;
场景一虚拟网络拓扑
Figure 11 场景一虚拟网络拓扑
如图我们有一个外网&＃xff08;External Network&＃xff09;&＃xff0c;IP段为172.16.0.0/16&＃xff0c;两个内网&＃xff0c;分别是Internal&＃xff1a;10.18.0.0/24&＃xff0c;和Internal2&＃xff1a;10.22.22.0/24&＃xff0c;值得注意的是这是两个网络&＃xff08;network&＃xff09;&＃xff0c;而不是子网&＃xff08;subnet&＃xff09;。
在这个场景下&＃xff0c;计算节点的内部应当是这样的&＃xff1a;
计算节点网络连接原理
下面我将解释如何得到这幅图。首先我们看下我们的虚拟机在libvirt的名称&＃xff0c;通过 nova show 命令我们大概可以获得像这样输出&＃xff08;截取前半部分&＃xff09;&＃xff1a;
| &＃43;--------------------------------------&＃43;------------------------------- | | Property | Value | &＃43;--------------------------------------&＃43;------------------------------- | Internal network | 10.18.0.3, 172.16.19.232 | | OS-DCF:diskConfig | MANUAL | | OS-EXT-AZ:availability_zone | nova | | OS-EXT-SRV-ATTR:host | compute1 | | OS-EXT-SRV-ATTR:hypervisor_hostname | compute1 | | OS-EXT-SRV-ATTR:instance_name | instance-0000001e | |
我们看到这台虚拟机被部署在compute1节点上&＃xff0c;instance_name为instance-0000001e&＃xff0c;我们上compute1节点使用virsh dumpxml将instance-0000001e的信息打印出来&＃xff08;截取网络相关&＃xff09;&＃xff1a;
在这里我们看到这台虚拟机的网络设备是tap48e06cd2-60&＃xff0c;而且似乎连到了qbr48e06cd2-60上&＃xff0c;让我们用brctl show再看下&＃xff08;截取相关部分&＃xff09;&＃xff1a;
| qbr48e06cd2-60 8000.bed5536ff312 no qvb48e06cd2-60tap48e06cd2-60 |
看到这里网桥qbr48e06cd2-60上接了两个接口&＃xff0c;qvb48e06cd2-60和tap48e06cd2-60&＃xff0c;其中的tap设备是我们虚拟机使用的虚拟网络设备&＃xff0c;那qvb48e06cd2-60是什么&＃xff1f;我们先用lshw –class network把所有网络设备打印出来&＃xff08;截取相关部分&＃xff09;&＃xff1a;
| *-network:5description: Ethernet interface physical id: 7 logical name: qvb48e06cd2-60 serial: be:d5:53:6f:f3:12 size: 10Gbit/s capabilities: ethernet physical configuration: autonegotiation&＃61;off broadcast&＃61;yes driver&＃61;veth driverversion&＃61;1.0 duplex&＃61;full firmware&＃61;N/A link&＃61;yes multicast&＃61;yes port&＃61;twisted pair promiscuous&＃61;yes speed&＃61;10Gbit/s |
我们注意到这里显示这个设备的driver是veth&＃xff0c;而veth总是成对出现的&＃xff0c;我们用ethtool -S 看下这个veth的另一端连到了那里&＃xff1a;
| # ethtool -S qvb48e06cd2-60NIC statistics: peer_ifindex: 16 |
OK&＃xff0c;看下16号是哪个设备&＃xff0c;ip link&＃xff08;截取相关部分&＃xff09;&＃xff1a;
| 16: qvo48e06cd2-60: mtu 1500 qdisc pfifo_fast state UP qlen 1000link/ether aa:c0:0f:d2:e2:43 brd ff:ff:ff:ff:ff:ff |
通过上面两个步骤我们已经知道了这对从虚拟机的网络设备到veth pair这个流程&＃xff0c;这个过程在官方文档中针对不同的 Libvirt VIF Driver有不同的简单的描述&＃xff0c;见 https://wiki.openstack.org/wiki/LibvirtVIFDrivers 。
下面应该是连到Open vSwitch上吧&＃xff0c;让我们验证下&＃xff1a;
1910d375-2692-4214-acdf-d364382c25a4
Bridge br-int
Port br-int
Interface br-int
type: internal
Port patch-tun
Interface patch-tun
type: patch
options: {peer&＃61;patch-int}
Port "qvo48e06cd2-60"
tag: 1
Interface "qvo48e06cd2-60"
Port "qvodfdc29e2-9a"
tag: 2
Interface "qvodfdc29e2-9a"
Port "qvo18cec000-80"
tag: 2
Interface "qvo18cec000-80"
Port "qvob86d15f1-8f"
tag: 1
Interface "qvob86d15f1-8f"
Bridge br-tun
Port br-tun
Interface br-tun
type: internal
Port patch-int
Interface patch-int
type: patch
options: {peer&＃61;patch-tun}
Port "gre-1"
Interface "gre-1"
type: gre
options: {in_key&＃61;flow, local_ip&＃61;"192.168.10.11", out_key&＃61;flow, remote_ip&＃61;"192.168.10.10"}
ovs_version: "1.11.0"
果然qvo48e06cd2-60是连到了br-int上&＃xff0c; OpenStack采用这么复杂的机制&＃xff0c;而不是把tap设备直接连到Open vSwitch上&＃xff0c;这与安全组有关&＃xff0c;将在3.2.4基于iptables的Security Group介绍。
在研究到OVS内部前&＃xff0c;我们先注意下在poty “qvo48e06cd2-60”下有一个“tag: 1”&＃xff0c;这个tag是Open vSwitch用来区分不同子网的。在这里&＃xff0c;tag1表示我们的10.18.0.0/24子网&＃xff0c;tag2表示10.22.22.0/24子网。
br-int和br-tun通过patch连接&＃xff0c;在官方文档上patch的介绍并不多&＃xff0c;但一旦两个OVS网桥通过网桥连接&＃xff0c;这两个网桥将近乎为同一个网桥&＃xff0c;参考资料见&＃xff1a; Open vSwitch FAQ 和 Connecting OVS Bridges with Patch Ports 。
首先看下bt-int的流表规则&＃xff1a;
| # ovs-ofctl dump-flows br-intNXST_FLOW reply (xid&＃61;0×4): COOKIE&＃61;0×0, duration&＃61;246746.016s, table&＃61;0, n_packets&＃61;702, n_bytes&＃61;78521, idle_age&＃61;1324, hard_age&＃61;65534, priority&＃61;1 actions&＃61;NORMAL |
只有一个NORMAL的动作&＃xff0c;在Open vSwitch的官方文档里解释为将包以传统的&＃xff0c;非OpenFlow的方式进行交换&＃xff0c;也就是说效果和没设置OpenFlow规则一样&＃xff08;见 Open vSwitch Advanced Features Tutorial &＃xff09;。那么我们分析br-tun的流表规则&＃xff0c;首先在计算节点上用ovs-ofctl dump-ports-desc查看br-tun上所有接口&＃xff1a;
| OFPST_PORT_DESC reply (xid&＃61;0x2):1(patch-int): addr:ea:a2:71:f5:9f:ad config: 0 state: 0 speed: 0 Mbps now, 0 Mbps max 2(gre-1): addr:d6:89:b0:03:d2:72 config: 0 state: 0 speed: 0 Mbps now, 0 Mbps max LOCAL(br-tun): addr:9a:49:9a:35:d1:4e config: 0 state: 0 speed: 0 Mbps now, 0 Mbps max |
然后用ovs-ofctl dump-flows或者EasyOVS查看br-tun的流表规则&＃xff08;这里使用EasyOVS使排版相对好看&＃xff09;&＃xff1a;
| ID TAB PKT PRI MATCH ACT 0 0 339 1 in&＃61;1 resubmit(,1) 1 0 285 1 in&＃61;2 resubmit(,2) 2 0 3 0 * drop 3 1 216 0 dl_dst&＃61;00:00:00:00:00:00/01:00:00:00:00:00 resubmit(,20) 4 1 123 0 dl_dst&＃61;01:00:00:00:00:00/01:00:00:00:00:00 resubmit(,21) 5 10 363 1 * learn(table&＃61;20,hard_timeout&＃61;300,priority&＃61;1,NXM_OF_VLAN_TCI[0..11],NXM_OF_ETH_DST[]&＃61;NXM_OF_ETH_SRC[],load:0->NXM_OF_VLAN_TCI[],load:NXM_NX_TUN_ID[]->NXM_NX_TUN_ID[],output:NXM_OF_IN_PORT[]),output:1 6 2 341 1 tun_id&＃61;0x2 mod_vlan_vid:1,resubmit(,10) 7 2 17 1 tun_id&＃61;0x3 mod_vlan_vid:2,resubmit(,10) 8 2 3 0 * drop 9 20 0 0 * resubmit(,21) 10 21 3 1 vlan&＃61;2 strip_vlan,set_tunnel:0x3,output:2 11 21 16 1 vlan&＃61;1 strip_vlan,set_tunnel:0x2,output:2 12 21 4 0 * drop 13 3 0 0 * drop |
这里为了好看只显示了ID、表名、计数器、匹配规则和行为。先看这几条流&＃xff1a;0、3、4、9、10、11、12&＃xff0c;这些流定义了从br-int进入的包的行为&＃xff0c;逐条从上往下看&＃xff1a;
| 0. 表0&＃xff1a;当匹配到从port 1&＃xff08;patch-int&＃xff09;进入的包时&＃xff0c;提交给表1继续匹配&＃xff1b;3. 表1&＃xff1a;当目标MAC地址为单播地址时&＃xff0c;提交给表20继续匹配&＃xff1b; 4. 表1&＃xff1a;当目标MAC地址为多播/广播地址时&＃xff0c;提交给表21继续匹配&＃xff1b;、 9. 表20&＃xff1a;提交给21继续匹配&＃xff08;这个表并非只是转发&＃xff0c;当OVS根据表10动态建立自动学习的规则时&＃xff0c;会添加到表20&＃xff0c;比如下面这条流表规则是自动建立的目标MAC地址为路由的规则&＃xff1a;“COOKIE &＃61; 0×0, duration &＃61; 11.099s, table &＃61; 20, n_packets &＃61; 45, n_bytes &＃61; 6132, hard_timeout &＃61; 300, idle_age &＃61; 3, hard_age &＃61; 2, priority &＃61; 1,vlan_tci &＃61; 0×0001/0x0fff,dl_dst &＃61; fa:16:3e:a1:3f:19 actions &＃61; load:0 -> NXM_OF_VLAN_TCI[], load:0×2 -> NXM_NX_TUN_ID[], output:2”&＃xff09;&＃xff1b; 10. 表21&＃xff1a;当目标VLan标签为2时&＃xff0c;剥去VLan标签&＃xff0c;然后将Tunnel Key设置为3&＃xff08;GRE通道的Key&＃xff0c;详见 rfc2890 的相关描述&＃xff09;并从port 2&＃xff08;gre-1&＃xff09;发出去&＃xff1b; 11. 表21&＃xff1a;当目标VLan标签为1时&＃xff0c;剥去VLan标签&＃xff0c;然后将Tunnel Key设置为2并从port 2&＃xff08;gre-1&＃xff09;发出去&＃xff1b; 12. 表21&＃xff1a;对没成功匹配的包&＃xff0c;丢弃。 |
再看1、6、7、5&＃xff0c;这几个流定义了来自GRE通道&＃xff08;Network节点&＃xff09;的包的行为&＃xff1a;
| 1. 表0&＃xff1a;当匹配到从port 2&＃xff08;gre-1&＃xff09;进入的包时&＃xff0c;提交给表2继续匹配&＃xff1b;6. 表2&＃xff1a;当Tunnel Key为2时&＃xff0c;添加VLan tag 1&＃xff0c;提交给表10继续匹配&＃xff1b; 7. 表2&＃xff1a;当Tunnel Key为3时&＃xff0c;添加VLan tag 2&＃xff0c;提交给表10继续匹配&＃xff1b; 5. 表10&＃xff1a;首先从报文中学习VLan、MAC等信息并把规则添加表20&＃xff0c;然后再从port 1&＃xff08;patch-int&＃xff09;发出去。 |
至此&＃xff0c;计算节点的网络分析已经基本完成。后面到网络节点的连接等主要涉及到3层路由&＃xff0c;暂且不表。
京公网安备 11010802041100号