ITPub博客

首页 > 云计算 > 虚拟化 > Openstack Neutron Provider Network虚机数据流

Openstack Neutron Provider Network虚机数据流

虚拟化 作者:hxw2ljj 时间:2015-11-18 08:56:46 0 删除 编辑
摘要 Openstack Neutron Provider Network虚机数据流

本文分析了一下neutron provider network的环境下虚拟机数据流。


实验环境如下:

Openstack : Havana (Neutron ML2+openvswitch agent, Vlan模式)

Provider Network : Vlan 100, 网段 100.100.100.0/24, 网关100.100.100.1


虚机网络拓扑环境如下:


我们以在虚拟机中ping 8.8.8.8为例说明数据流。


在虚机中当我们敲下ping 8.8.8.8以后, 我们的kernel会查找路由表看看我们有没有8.8.8.8的路由。
在虚机中ifconfig和ip route的结果如下:

# ifconfig 
eth0 Link encap:Ethernet HWaddr FA:16:3E:2E:FD:E1
          inet addr:100.100.100.2 Bcast:100.100.100.255 Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:1906 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1709 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:147567 (144.1 KiB) TX bytes:233064 (227.6 KiB)
# ip route show
169.254.169.254 via 100.100.100.3 dev eth0 proto static
100.100.100.0/24 dev eth0 proto kernel scope link src 100.100.100.2
169.254.0.0/16 dev eth0 scope link metric 1002
default via 100.100.100.1 dev eth0 


我们发现在虚机中并没有到8.8.8.8的直连路由,因此我们会把包发送给默认网关100.100.100.1。
此时我们首先会发送ARP广播请求默认网关的MAC。当默认网关会应我们ARP请求后,我们就得到了需要的默认网关的MAC。
我们会将ICMP Request包发出,这个包源IP是100.100.100.2,目的IP是8.8.8.8,源MAC是FA:16:3E:2E:FD:E1,目的MAC是默认网关的MAC。


之后这个包就被发送到了tapdfc176e4-5a。
下面是tapdfc176e4-5a在计算节点上的相关配置:
# ifconfig tapdfc176e4-5a
tapdfc176e4-5a Link encap:Ethernet HWaddr FE:16:3E:2E:FD:E1
          inet6 addr: fe80::fc16:3eff:fe2e:fde1/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:217 errors:0 dropped:0 overruns:0 frame:0
          TX packets:249 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500
          RX bytes:28180 (27.5 KiB) TX bytes:21472 (20.9 KiB)


# brctl show
bridge name bridge idSTP enabledinterfaces
qbr6750eac8-57 8000.d6c128fae672noqvb6750eac8-57
       tap6750eac8-57
qbrdfc176e4-5a 8000.7e07e8dd1cf6noqvbdfc176e4-5a
       tapdfc176e4-5a
virbr0 8000.525400e75eaayesvirbr0-nic


此处可以看到tapdfc176e4-5a被连接到了linux bridge qbrdfc176e4-5a上,而不是连接到OVS的br-int上。原因是如果将tapdfc176e4-5a直接连到br-int上,Security Group就没有机会执行过滤规则。 
目前Security Group是用iptables实现的。在iptables中有一个feature叫做bridge-nf-call-iptables,可以过滤桥上的流。我们可以通过以下命令查看是否开启: 
# cat /proc/sys/net/bridge/bridge-nf-call-iptables 
1 


我们可以使用iptables -nvL 查看这个VM在filter表中的Security Group: 
Chain neutron-openvswi-idfc176e4-5 (1 references) 
 pkts bytes target prot opt in out source destination  
    0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID  
  318 20107 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED  
    1 60 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22  
    0 0 RETURN udp -- * * 100.100.100.3 0.0.0.0/0 udp spt:67 dpt:68  
    0 0 RETURN udp -- * * 100.100.100.4 0.0.0.0/0 udp spt:67 dpt:68  
    0 0 neutron-openvswi-sg-fallback all -- * * 0.0.0.0/0 0.0.0.0/0  
Chain neutron-openvswi-odfc176e4-5 (2 references) 
 pkts bytes target prot opt in out source destination 
    0 0 RETURN udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:68 dpt:67 
  299 31689 neutron-openvswi-sdfc176e4-5 all -- * * 0.0.0.0/0 0.0.0.0/0 
    0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:67 dpt:68 
    0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID 
  295 31365 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 
    4 324 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 
    0 0 neutron-openvswi-sg-fallback all -- * * 0.0.0.0/0 0.0.0.0/0   


在Neutron中会对进入/流出虚机的流量进行过滤,neutron-openvswi-idfc176e4-5链是进入虚机流的访问控制规则。neutron-openvswi-odfc176e4-5链是流出虚机流的访问控制规则。 
这两个连是在neutron-openvswi-sg-chain中被调用的: 
Chain neutron-openvswi-sg-chain (4 references) 
 pkts bytes target prot opt in out source destination 
  319 20167 neutron-openvswi-idfc176e4-5 all -- * * 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-out tapdfc176e4-5a --physdev-is-bridged 
  299 31689 neutron-openvswi-odfc176e4-5 all -- * * 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-in tapdfc176e4-5a --physdev-is-bridged  


在packet从桥和Security Group流出后,他会来到br-int的qvodfc176e4-5a,这个接口可以看到是"tag: 2",这表示这个接口是"Access口",vlan id是2。 
OVS输出如下: 
# ovs-vsctl show 
47115847-b828-47f3-bbdb-e18d4b0fd11e 
    Bridge br-int 
        Port "tap39b2b891-3b" 
            tag: 2 
            Interface "tap39b2b891-3b" 
                type: internal 
        Port br-int 
            Interface br-int 
                type: internal 
        Port "qvo6750eac8-57" 
            tag: 1 
            Interface "qvo6750eac8-57" 
        Port "qvodfc176e4-5a" 
            tag: 2 
            Interface "qvodfc176e4-5a" 
        Port "int-br-eth2" 
            Interface "int-br-eth2" 
        Port "qr-441abe6b-8b" 
            tag: 1 
            Interface "qr-441abe6b-8b" 
                type: internal 
    Bridge br-ex 
        Port br-ex 
            Interface br-ex 
                type: internal 
        Port "qg-019b0743-e4" 
            Interface "qg-019b0743-e4" 
                type: internal 
        Port "eth3" 
            Interface "eth3" 
    Bridge "br-eth2" 
        Port "eth2" 
            Interface "eth2" 
        Port "br-eth2" 
            Interface "br-eth2" 
                type: internal 
        Port "phy-br-eth2" 
            Interface "phy-br-eth2" 
    ovs_version: "1.11.0" 

虚拟交换机br-int会将packet从int-br-eth2发送出去,而"int-br-eth2"和"phy-br-eth2"是veth pair,因此包会从phy-br-eth2流入br-eth2,以下是OVS的openflow输出: 
# ovs-ofctl show br-eth2 
OFPT_FEATURES_REPLY (xid=0x2): dpid:00000800270731f9 
n_tables:254, n_buffers:256 
capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP 
actions: OUTPUT SET_VLAN_VID SET_VLAN_PCP STRIP_VLAN SET_DL_SRC SET_DL_DST SET_NW_SRC SET_NW_DST SET_NW_TOS SET_TP_SRC SET_TP_DST ENQUEUE 
 1(eth2): addr:08:00:27:07:31:f9 
     config: 0 
     state: 0 
     speed: 0 Mbps now, 0 Mbps max 
 2(phy-br-eth2): addr:a2:e1:41:5c:cc:bf 
     config: 0 
     state: 0 
     current: 10GB-FD COPPER 
     speed: 10000 Mbps now, 0 Mbps max 
 LOCAL(br-eth2): addr:08:00:27:07:31:f9 
     config: 0 
     state: 0 
     speed: 0 Mbps now, 0 Mbps max 
OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0 


# ovs-ofctl dump-flows br-eth2 
NXST_FLOW reply (xid=0x4): 
 cookie=0x0, duration=3968.876s, table=0, n_packets=20, n_bytes=2052, idle_age=1947, priority=4,in_port=2,dl_vlan=1 actions=mod_vlan_vid:1001,NORMAL 
 cookie=0x0, duration=3967.173s, table=0, n_packets=218, n_bytes=28424, idle_age=502, priority=4,in_port=2,dl_vlan=2 actions=mod_vlan_vid:100,NORMAL 
 cookie=0x0, duration=3972.688s, table=0, n_packets=10, n_bytes=764, idle_age=1986, priority=2,in_port=2 actions=drop 
 cookie=0x0, duration=3976.268s, table=0, n_packets=411, n_bytes=77162, idle_age=14, priority=1 actions=NORMAL 


我们需要特别关注以下openflow条目: 
 cookie=0x0, duration=3967.173s, table=0, n_packets=218, n_bytes=28424, idle_age=502, priority=4,in_port=2,dl_vlan=2 actions=mod_vlan_vid:100,NORMAL 

"dl_vlan=2" 是说当packet的vlan tag为2。我们的packet是从Tag为2的"Access口"进来的,因此会带有tag为2的vlan头。 
"action = mod_vlan_vid:100" 执行修改vlan头的action,将vlan id改为100。 
"NORMAL" 执行标准交换机动作。 


也就是说在br-eth2上的openflow规则会将我们的packet转为vlan id为100的packet。我们回过头来看br-int的openflow条目,会发现也有类似规则,不过是将vlan id从100改为2。 
下面是br-int上的openflow条目: 
# ovs-ofctl show br-int 
OFPT_FEATURES_REPLY (xid=0x2): dpid:000032774807d443 
n_tables:254, n_buffers:256 
capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP 
actions: OUTPUT SET_VLAN_VID SET_VLAN_PCP STRIP_VLAN SET_DL_SRC SET_DL_DST SET_NW_SRC SET_NW_DST SET_NW_TOS SET_TP_SRC SET_TP_DST ENQUEUE 
 1(int-br-eth2): addr:4e:1d:f3:fe:23:12 
     config: 0 
     state: 0 
     current: 10GB-FD COPPER 
     speed: 10000 Mbps now, 0 Mbps max 
 2(qvodfc176e4-5a): addr:36:92:d2:25:b7:8d 
     config: 0 
     state: 0 
     current: 10GB-FD COPPER 
     speed: 10000 Mbps now, 0 Mbps max 
 3(qr-441abe6b-8b): addr:f6:01:00:00:00:00 
     config: PORT_DOWN 
     state: LINK_DOWN 
     speed: 0 Mbps now, 0 Mbps max 
 4(qvo6750eac8-57): addr:fe:63:44:8b:9d:28 
     config: 0 
     state: 0 
     current: 10GB-FD COPPER 
     speed: 10000 Mbps now, 0 Mbps max 
 7(tap39b2b891-3b): addr:f6:01:00:00:00:00 
     config: PORT_DOWN 
     state: LINK_DOWN 
     speed: 0 Mbps now, 0 Mbps max 
 LOCAL(br-int): addr:32:77:48:07:d4:43 
     config: 0 
     state: 0 
     speed: 0 Mbps now, 0 Mbps max 
OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0 


# ovs-ofctl dump-flows br-int 
NXST_FLOW reply (xid=0x4): 
 cookie=0x0, duration=3960.902s, table=0, n_packets=2, n_bytes=748, idle_age=1949, priority=3,in_port=1,dl_vlan=1001 actions=mod_vlan_vid:1,NORMAL 
 cookie=0x0, duration=3959.222s, table=0, n_packets=242, n_bytes=21940, idle_age=494, priority=3,in_port=1,dl_vlan=100 actions=mod_vlan_vid:2,NORMAL 
 cookie=0x0, duration=3965.248s, table=0, n_packets=166, n_bytes=54124, idle_age=6, priority=2,in_port=1 actions=drop 
 cookie=0x0, duration=3969.286s, table=0, n_packets=608, n_bytes=69908, idle_age=494, priority=1 actions=NORMAL 


当我们的packet在br-eth2上被转发到eth2,并带有vlan id 100从eth2上发送出去,就会发送到物理交换机上。物理交换机与compute节点是通过trunk连接的,只要配置了vlan100就能将包转发到网关上,最后由网关将包转发出去。

来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/18796236/viewspace-1840109/ ,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2010-11-22

  • 博文量
    58
  • 访问量
    60126