neutron DVR

DVR 簡介

DVR 提出的背景

在 Neutron 的網絡環境中,跨子網的虛機通訊是須要經過 Neutron 的路由器。這既包括不一樣子網的虛擬機之間的通訊,又包括虛擬機與外網之間的通訊。在 DVR 被提出以前, 因爲 Neutron 的 legacy router 只會部署在網絡節點上,所以會形成網絡節點的流量過大,從而產生了兩個問題,其一是網絡節點將成爲整個 Neutron 網絡的瓶頸,其二是網絡節點單點失敗的問題。在這樣的背景下,OpenStack 社區在 Juno 版本里正式引入了 DVR(Distributed Virtual Router)。DVR,顧名思義就是 Neutron 的 router 將不僅僅部署在網絡節點上,全部啓動了 Neutron L3 Agent 的節點,都會在必要時在節點上建立 Neutron router 對應的 namepsace,並更新與 DVR router 相關的 Openflow 規則,從而完成 DVR router 在該節點上的部署。在計算節點上部署了 DVR router 後,E-W 方向上的流量再也不須要將數據包發送到網絡節點後再轉發,而是有本地的 DVR router 直接進行跨子網的轉發;N-S 方向上,對於綁定了 floating IP 的虛機,其與外網通訊時的數據包也將直接經過本地的 DVR router 進行轉發。從而,Neutron 網絡上的一些流量被分攤開,有效地減小了網絡節點上的流量;通訊再也不必須經過網絡節點,也提高了 Neutron 網絡的抗單點失敗的能力。html

本文主要講解的是 E-W 方向上的虛擬機通訊狀況。node

非 DVR 和 DVR 狀況下,網絡節點流量對比

這是在有相同數量的虛機的狀況下的對比。linux

  • 非 DVR 的狀況,網絡節點的流量狀況
1
2
3
4
5
6
7
8
9
10
11
12
13
14
[root@test114 openvswitch]# ifstat
#kernel
Interface RX Pkts/Rate TX Pkts/Rate RX Data/Rate TX Data/Rate
RX Errs/Drop TX Errs/Drop RX Over/Rate TX Coll/Rate
lo 19090K 0 19090K 0 18446744071513M 0 18446744071513M 0
0 0 0 0 0 0 0 0
eth0 116688K 0 1737K 0 674575K 0 555880K 0
0 0 0 0 0 0 0 0
eth1 118480K 0 286 0 18446744070647M 0 71696 0
0 0 0 0 0 0 0 0
br-eth1 8650K 0 80 0 1580M 0 3360 0
0 1127 0 0 0 0 0 0
br-ex 10276K 0 1737K 0 18446744071533M 0 555877K 0
0 1127 0 0 0 0 0 0
  • 在 DVR enabled 的狀況下,網絡節點的流量狀況
1
2
3
4
5
6
7
8
9
10
11
12
13
14
[root@test114 ~]# ifstat
#kernel
Interface RX Pkts/Rate TX Pkts/Rate RX Data/Rate TX Data/Rate
RX Errs/Drop TX Errs/Drop RX Over/Rate TX Coll/Rate
lo 2155 0 2155 0 790717 0 790717 0
0 0 0 0 0 0 0 0
eth0 10461 0 213 0 2310K 0 88001 0
0 0 0 0 0 0 0 0
eth1 10683 0 0 0 2399K 0 0 0
0 0 0 0 0 0 0 0
br-eth1 528 0 0 0 90626 0 0 0
0 0 0 0 0 0 0 0
br-ex 800 0 213 0 173756 0 88001 0
0 0 0 0 0 0 0 0

在非 DVR 和 DVR 的狀況下,數據包流經各節點的對比

DVR 支持 VLAN、GRE、VXLAN 這幾種網絡類型,但由於方便起見(VLAN 須要開啓路由器的 Trunk 口),因此本文中,咱們這就用 GRE 做爲環境的網絡類型。咱們這裏的環境狀況以下:cookie

網絡節點是 test114.sce.ibm.com, 兩個計算節點分別是 test115.sce.ibm.com 和 test116.sce.ibm.com,兩個私有網絡分別是 gre(192.168.11.0/24),gre1(192.168.12.0/24),都是 GRE 類型的,它們經過 router 相連,在兩個計算節點上面分別有一臺虛擬機,它們分屬不一樣的網絡。這裏面 VM1 在 test115.sce.ibm.com 上,ip 地址是 192.168.11.3, VM2 在 test116.sce.ibm.com 上,ip 地址是 192.168.12.4。網絡

  • 非 DVR 的狀況:
    圖 1.非 DVR
    非 DVR
    1
    2
    3
    4
    5
    6
    7
    8
    9
    [root@test115 ~] tcpdump |grep -i "gre"
    18:14:11.794450 IP test115.sce.ibm.com > test114.sce.ibm.com: GREv0, key=0x1, length 106:
    IP 192.168.11.3 > 192.168.12.4: ICMP echo request, id 16641, seq 23588, length 64
    18:14:11.794550 IP test114.sce.ibm.com > test116.sce.ibm.com: GREv0, key=0x2, length 106:
    IP 192.168.11.3 > 192.168.12.4: ICMP echo request, id 16641, seq 23588, length 64
    18:14:11.796136 IP test116.sce.ibm.com > test114.sce.ibm.com: GREv0, key=0x2, length 106:
    IP 192.168.12.4 > 192.168.11.3: ICMP echo reply, id 16641, seq 23588, length 64
    18:14:11.796198 IP test114.sce.ibm.com > test115.sce.ibm.com: GREv0, key=0x1, length 106:
    IP 192.168.12.4 > 192.168.11.3: ICMP echo reply, id 16641, seq 23588, length 64
  • DVR 的狀況:
    圖 2.DVR
    DVR
    1
    2
    3
    4
    16:34:02.479531 IP test115.sce.ibm.com > test116.sce.ibm.com: GREv0, key=0x2, length 106:
      IP 192.168.11.3 > 192.168.12.4: ICMP echo request, id 10241, seq 19852, length 64
    16:34:02.482082 IP test116.sce.ibm.com > test115.sce.ibm.com: GREv0, key=0x1, length 106:
    IP 192.168.12.4 > 192.168.11.3: ICMP echo reply, id 10241, seq 19852, length 64

在非 DVR 的狀況,數據是要經過網絡節點才能相互傳遞數據包;在 DVR 的狀況,數據包是直接在兩個計算節點上傳遞。tcp

配置 DVR

配置文件

在網絡節點和計算節點配置 DVR:oop

  • 網絡節點:由於 DVR 是屬於 l3-agent 的功能,並依賴於 l3-agent,因此咱們在這裏的改動應該默認爲環境上的 l3-agent 是能夠工做的。具體配置以下:

    修改對應文件:spa

    neutron.conf : router_distributed = True3d

    l3_agent.ini : agent_mode = dvr_snatcode

    ovs_neutron_plugin.ini : l2_population = True and enable_distributed_routing = True

    ml2_conf.ini : mechanism_drivers = openvswitch,linuxbridge,l2population

    從新啓動 neutron-openvswitch-agent, netron-l3-agent, neutron-server 服務。

  • 計算節點:考慮到 compute node 上可能在 enable DVR 以前是沒有啓動/配置 DVR 的,那麼參照 network node 上的 l3_agent.ini 去配置 compute node,啓動 l3-agent。同時把 l3-agent 配置成 DVR 模式。還須要在節點上配置 br-ex 這個 ovs bridge,若是節點上在 enable DVR 以前沒有這個 ovs bridge,而且若是 compute node 上的虛機須要與外網通訊,那麼 compute node 上的 br-ex 就必須橋接到一個能夠鏈接到外網的網卡上。具體配置以下:

    把節點配置成 DVR 模式:

    l3_agent.ini : agent_mode = dvr

    ovs_neutron_plugin.ini : l2_population = True and enable_distributed_routing = True

    從新啓動 neutron-openvswitch-agent, netron-l3-agent 服務。

    創建 br-ex 網橋,使得 eth0 上的 ip 地址轉移到 br-ex 上。具體操做以下:

    創建 br-ex: ovs-vsctl add-br br-ex

    把 eth0 橋接到 br-ex 裏面:ovs-vsctl add-port br-ex "eth0"

    創建 ifcfg-br-ex, ifcfg-eth0 is in /etc/sysconfig/network-scripts。

    從新啓動網絡服務。使得配置生效。

  • 遷移到 DVR 模式。使得新添加的 l3-agent 可以管理 router,(若是是先 enabled DVR,再創建網絡和 router,忽略這一步),具體操做以下:

    在網絡節點上執行以下操做:

    neutron router-update --admin_state_up=False ROUTER

    neutron router-update --distributed=True ROUTER

    neutron router-update --admin_state_up=True ROUTER

    查看 router 是否已經和三個 l3-agent 對應

    1
    2
    3
    4
    5
    6
    7
    [root@test114 ~]# neutron  l3-agent-list-hosting-router router2
    +--------------------------------------+---------------------+----------------+-------+
    | id | host | admin_state_up | alive |
    +--------------------------------------+---------------------+----------------+-------+
    | 26a3a232-888b-4b6d-8f81-5bdd2b988414 | test114.sce.ibm.com | True | :-) |
    | 818537d8-903a-4ff9-a745-2d562ab82e54 | test115.sce.ibm.com | True | :-) |
    | 427b251d-b210-4782-9d96-858c30181dbe | test116.sce.ibm.com | True | :-) |

計算節點上的虛擬機的數據流的傳遞

當在虛擬機 VM1(test115.sce.ibm.com)裏面去 ping VM2 的 IP 的時候,數據包先轉到宿主機的網橋 br-int 上,數據先傳到那個和 VM1 的 port 匹配的 port 端口上,轉到網關所在的那個端口,再轉到 namespace 裏,找到網關所在的端口,再轉回 br-int,而後經過 br-int 上面的 patch-tun 端口傳遞到 br-tun 這個網橋上,在 br-tun 網橋上的對應的端口經過 trunk 傳遞數據包到 VM2 所在的宿主機(test116.sce.ibm.com)的 br-tun 上的對應端口,再經過 patch-int 傳到 br-int 上的 patch-tun,經過 br-int 上的與 VM2 對應的 port 端口,把數據傳遞給 VM2,完成數據包的傳遞。簡單的能夠寫成 vm1->br-int->namespace->br-int>br-tun->tunnel>br-tun->br-int->vm2。

DVR 環境下 Openflow 規則的分析

OVS 命令簡介

Open VSwitch(OVS)是一個虛擬交換機,能夠用來組成虛擬網絡。OpenStack Neutron 裏面也是應用了 OVS, Neutron 的 router 雖然是工做在網絡 3 層的,看似與 2 層的 OVS 無關,但實際上 Neutron router 在轉發不一樣子網之間的數據流量時,仍是須要藉助 2 層 Openflow 規則,而且 Neutron router 的 namespace 中的子網網關的端口設備等都是須要接在 OVS 的網橋 br-int 上才能工做的。DVR 做爲 Neutron router 的一種特殊實現,本質上也是依賴於 OVS 的,這一點與 Neutron legacy router 並沒有差別。在前面 DVR 的配置中咱們用到了一些 OVS 的命令,這裏再介紹一下 OVS 的一些命令:

  • 查看 open vswitch 的網絡狀態:ovs-vsctl show
  • 查看網橋 br-tun 的接口情況:ovs-ofctl show br-tun
  • 查看網橋 br-tun 的流表:ovs-ofctl dump-flows br-tun
  • 添加網橋:#ovs-vsctl add-br br0
  • 將物理網卡掛接到網橋:#ovs-vsctl add-port br0 eth0

咱們這片文章裏面主要用到了以上五個個 ovs 命令。咱們在提一下其它的一些命令。

  • 列出 open vswitch 中的全部網橋:#ovs-vsctl list-br
  • 判斷網橋是否存在:#ovs-vsctl br-exists br0
  • 列出網橋中的全部端口:#ovs-vsctl list-ports br0
  • 列出全部掛接到網卡的網橋:#ovs-vsctl port-to-br eth0
  • 刪除網橋上已經掛接的網口:#vs-vsctl del-port br0 eth0
  • 刪除網橋:#ovs-vsctl del-br br0

數據包在 br-int 和 br-tun 上的流表

在前面的章節,大體描述了一下數據包的流動狀況,在這裏再來看一下 br-int 和 br-tun 上的流表,具體來看下數據包的傳遞。

當從 VM1(192.168.11.14) 去 ping VM2(192.168.12.9), 數據包首先流到 compute1(10.11.1.115)的 br-int 上,讓咱們先看看 compute1 上的網絡狀態。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
[root@test115 ~]# ovs-vsctl show
1799e6ea-b3b0-4581-b42e-e1bfd8a5d96d
Bridge br-ex
Port "eth0"
Interface "eth0"
Port br-ex
Interface br-ex
type: internal
Bridge br-tun
fail_mode: secure
Port "gre-0a0b0174"
Interface "gre-0a0b0174"
type: gre
options: {df_default="true", in_key=flow, local_ip="10.11.1.115",
out_key= flow, remote_ip="10.11.1.116"}
Port br-tun
Interface br-tun
type: internal
Port patch-int
Interface patch-int
type: patch
options: {peer=patch-tun}
Port "gre-0a0b0172"
Interface "gre-0a0b0172"
type: gre
options: {df_default="true", in_key=flow, local_ip="10.11.1.115",
out_key= flow, remote_ip="10.11.1.114"}
Bridge "br-eth1"
Port "eth1"
Interface "eth1"
Port "phy-br-eth1"
Interface "phy-br-eth1"
type: patch
options: {peer="int-br-eth1"}
Port "br-eth1"
Interface "br-eth1"
type: internal
Bridge br-int
fail_mode: secure
Port "qr-43fad9d6-53"
tag: 1
Interface "qr-43fad9d6-53"
type: internal
Port patch-tun
Interface patch-tun
type: patch
options: {peer=patch-int}
Port "qr-c669122c-11"
tag: 2
Interface "qr-c669122c-11"
type: internal
Port br-int
Interface br-int
type: internal
Port "qvof76ecb29-5d"
tag: 2
Interface "qvof76ecb29-5d"
Port "int-br-eth1"
Interface "int-br-eth1"
type: patch
options: {peer="phy-br-eth1"}
ovs_version: "2.3.0"
 
[root@test114 neutron]# neutron port-list
+--------------------------------------+------+-------------------+-----------
---------------------------------------------------------------------------+
| id | name | mac_address | fixed_ips |
+--------------------------------------+------+-------------------+----------
----------------------------------------------------------------------------+
| 3086e492-b9b2-416a-9140-f01258c34dda | | fa:16:3e:e5:b9:08 | {"subnet_id":
"3eca2769-c97f-42a5-98e2-2ac41de54810", "ip_address": "192.168.11.2"}  |
| ed6b11e8-05ea-4024-8d83-b080984f084e | | fa:16:3e:b4:76:32 | {"subnet_id":
"ffd2c101-35e5-4758-ba75-43409e58adaf", "ip_address": "10.11.2.14"} |
| cf9fa480-7fd4-4e4b-b8cf-7f6c26cffb2d | | fa:16:3e:02:b7:c7 | {"subnet_id":
"3eca2769-c97f-42a5-98e2-2ac41de54810", "ip_address": "192.168.11.13"} |
| f76ecb29-5d9d-41fe-ae70-098502fda347 | | fa:16:3e:17:6b:a7 | {"subnet_id":
"3eca2769-c97f-42a5-98e2-2ac41de54810", "ip_address": "192.168.11.14"} |
| 2bbd30d4-86d4-4ccb-930a-edb7be55b740 | | fa:16:3e:2a:34:19 | {"subnet_id":
"8678e8ff-5f76-411b-9357-d2ab6ea6125a", "ip_address": "192.168.12.9"}  |
| 43fad9d6-53d3-4664-8fc1-defcfa21d78a | | fa:16:3e:a3:95:c2 | {"subnet_id":
"8678e8ff-5f76-411b-9357-d2ab6ea6125a", "ip_address": "192.168.12.1"}  |
| da445e04-ab74-409b-b5df-1f5e8f7aa955 | | fa:16:3e:42:25:42 | {"subnet_id":
"8678e8ff-5f76-411b-9357-d2ab6ea6125a", "ip_address": "192.168.12.2"}  |
| 76bfd868-976d-4483-8352-89e0522e213d | | fa:16:3e:d4:4d:ff | {"subnet_id":
"8678e8ff-5f76-411b-9357-d2ab6ea6125a", "ip_address": "192.168.12.10"} |
| 20f66057-a825-422c-9dfe-5bfa09292251 | | fa:16:3e:ee:70:14 | {"subnet_id":
"ffd2c101-35e5-4758-ba75-43409e58adaf", "ip_address": "10.11.2.10"} |
| c669122c-115f-42d5-b107-d346193cdb82 | | fa:16:3e:cd:50:8d | {"subnet_id":
"3eca2769-c97f-42a5-98e2-2ac41de54810", "ip_address": "192.168.11.1"}  |
+--------------------------------------+------+-------------------+----------------------
----------------------------------------------------------------+

從 VM1 的 port 信息裏面咱們得知,數據是從qvof76ecb29-5d口進入 br-int 的。咱們再看看 br-int 上的數據包, 從上面的 port 信息咱們查看到了相應的 MAC 地址,知道數據包是從 VM1 的 MAC 發到它 gateway 的 MAC 上的。而後在 namespace 裏面經過 VM2 的 gateway 端口轉發出來。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
[root@test115 ~]# ovs-ofctl dump-flows br-int
NXST_FLOW reply (xid=0x4):
cookie=0x0, duration=16439.298s, table=0, n_packets=476, n_bytes=46648, idle_age=8917,
priority=2,in_port=31,dl_src=fa:16:3f:ec:09:21 actions=resubmit(,1)
  cookie=0x0, duration=16439.451s, table=0, n_packets=0, n_bytes=0, idle_age=16439,
priority=4,in_port=30,dl_src=fa:16:3f:ec:09:21 actions=resubmit(,2)
  cookie=0x0, duration=16439.645s, table=0, n_packets=0, n_bytes=0, idle_age=16439,
priority=2,in_port=31,dl_src=fa:16:3f:1a:cf:03 actions=resubmit(,1)
  cookie=0x0, duration=16439.802s, table=0, n_packets=0, n_bytes=0, idle_age=16439,
priority=4,in_port=30,dl_src=fa:16:3f:1a:cf:03 actions=resubmit(,2)
  cookie=0x0, duration=16440.644s, table=0, n_packets=1074, n_bytes=104318, idle_age=8917,
priority=1 actions=NORMAL
  cookie=0x0, duration=16440.570s, table=0, n_packets=612165, n_bytes=339552066, idle_age=0,
priority=2,in_port=30 actions=drop
  cookie=0x0, duration=16440.800s, table=1, n_packets=0, n_bytes=0, idle_age=16440,
priority=1 actions=drop
  cookie=0x0, duration=16431.564s, table=1, n_packets=476, n_bytes=46648, idle_age=8917,
priority=4,dl_vlan=2,dl_dst=fa:16:3e:17:6b:a7
actions=strip_vlan,mod_dl_src:fa:16:3e:cd:50:8d,output:27
  cookie=0x0, duration=16440.720s, table=2, n_packets=0, n_bytes=0, idle_age=16440,
priority=1 actions=drop
  cookie=0x0, duration=16440.874s, table=23, n_packets=0, n_bytes=0, idle_age=16440,
priority=0 actions=drop

VM1 要 ping 的是 VM2,它們是在不一樣的網段上。經過 namespace,使得 192.168.12.1 和 192.168.11.1 這兩個 gateway 可以聯通,就把不一樣的兩個網段聯通起來。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
[root@test115 ~]# ip netns exec qrouter-a49eee39-7977-4a7f-81e1-dcbf57dbd904 ifconfig -a
lo: flags=73< UP ,LOOPBACK,RUNNING>  mtu 65536
inet 127.0.0.1  netmask 255.0.0.0
inet6 ::1  prefixlen 128  scopeid 0x10< host >
loop  txqueuelen 0  (Local Loopback)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 0  bytes 0 (0.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
qr-43fad9d6-53: flags=4163< UP ,BROADCAST,RUNNING,MULTICAST>  mtu 1500
inet 192.168.12.1  netmask 255.255.255.0  broadcast 192.168.12.255
inet6 fe80::f816:3eff:fea3:95c2  prefixlen 64  scopeid 0x20< link >
ether fa:16:3e:a3:95:c2  txqueuelen 0  (Ethernet)
RX packets 2  bytes 140 (140.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 2644  bytes 141732 (138.4 KiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
qr-c669122c-11: flags=4163< UP ,BROADCAST,RUNNING,MULTICAST>  mtu 1500
inet 192.168.11.1  netmask 255.255.255.0  broadcast 192.168.11.255
inet6 fe80::f816:3eff:fecd:508d  prefixlen 64  scopeid 0x20< link >
ether fa:16:3e:cd:50:8d  txqueuelen 0  (Ethernet)
RX packets 4091  bytes 395426 (386.1 KiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 3564  bytes 420291 (410.4 KiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

192.168.11.0/24 和 192.168.12.0/24 這兩個網段的通訊是分別經過qr-c669122c-11和qr-43fad9d6-53兩個端口,由於 namespace 的存在,它們自己是可以通訊的。

[root@test115 ~]# ip netns exec qrouter-a49eee39-7977-4a7f-81e1-dcbf57dbd904 ip route list table main

1
2
192.168.11.0/24 dev qr-c669122c-11  proto kernel  scope link  src 192.168.11.1
192.168.12.0/24 dev qr-43fad9d6-53  proto kernel  scope link  src 192.168.12.1

在 compute1 節點的 namespace 上可以獲得 192.168.12.9 的 MAC 地址及狀態。而且在 compute2 節點的 namespace 上可以獲得 192.168.11.14 的 MAC 地址及狀態。這些都保證了兩臺 VM 的順利通訊。

1
2
3
4
5
6
7
[root@test115 ~]# ip netns exec qrouter-a49eee39-7977-4a7f-81e1-dcbf57dbd904 ip nei
fe80::f4ce:f9ff:fe73:ef0d dev qr-c669122c-11 lladdr f6:ce:f9:73:ef:0d STALE
fe80::f816:3eff:fe17:6ba7 dev qr-c669122c-11 lladdr fa:16:3e:17:6b:a7 STALE
192.168.12.10 dev qr-43fad9d6-53 lladdr fa:16:3e:d4:4d:ff PERMANENT
192.168.11.14 dev qr-c669122c-11 lladdr fa:16:3e:17:6b:a7 PERMANENT
192.168.12.9 dev qr-43fad9d6-53 lladdr fa:16:3e:2a:34:19 PERMANENT
192.168.11.13 dev qr-c669122c-11 lladdr fa:16:3e:02:b7:c7 PERMANENT

數據包流入 br-int 以後,打上了 tag 2 標誌,接着 patch-tun 把 br-int 接入隧道橋 br-tun,咱們看到,patch-tun 和 patch-int 是對應的端口,咱們經過查看 br-tun 上的端口狀況得知數據流是從 port 8 進入 br-tun 的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
[root@test115 ~]# ovs-ofctl show br-tun
OFPT_FEATURES_REPLY (xid=0x2): dpid:00007e2d16238847
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
  8(patch-int): addr:f6:78:56:1e:33:fa
config: 0
state: 0
speed: 0 Mbps now, 0 Mbps max
  9(gre-0a0b0172): addr:d6:4a:8e:14:bc:63
config: 0
state: 0
speed: 0 Mbps now, 0 Mbps max
  10(gre-0a0b0174): addr:8a:c7:68:16:44:d8
config: 0
state: 0
speed: 0 Mbps now, 0 Mbps max
  LOCAL(br-tun): addr:7e:2d:16:23:88:47
config: PORT_DOWN
state: LINK_DOWN
speed: 0 Mbps now, 0 Mbps max
OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0

首先注意一下,數據流在進入 br-tun 以前,數據包已經轉化成了從 VM1 的 MAC ping 192.168.12.1 的 MAC。咱們查看一下數據在 br-tun 上的流表。數據首先流入 table0,流入端口是 port 8。接着進入 table1,流入地址就是 192.168.12.1 的 MAC 地址,它轉變成了 compute1 的 MAC 地址, 這個 MAC 地址咱們能夠從 db2 裏面獲得。接着進入 table2, 由於 ping 用的協議是 ICMP,因此這裏定位粗體字的這條數據流。接着進入 table20,從上面的 port list 表中,咱們能夠看到,數據流最終指向 VM2(192.168.12.9), 數據包從隧道 set_tunnel:0x2, port 10 流出。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
[root@test115 ~]# ovs-ofctl dump-flows br-tun
NXST_FLOW reply (xid=0x4):
  cookie=0x0, duration=108352.425s, table=0, n_packets=0, n_bytes=0, idle_age=65534,
hard_age=65534, priority=0 actions=drop
  cookie=0x0, duration=108343.696s, table=0, n_packets=476, n_bytes=46648, idle_age=65534,
  hard_age=65534, priority=1,in_port=10 actions=resubmit(,3)
  cookie=0x0, duration=108351.277s, table=0, n_packets=496, n_bytes=49088,
  idle_age=2304, hard_age=65534, priority=1,in_port=8 actions=resubmit(,1)
  cookie=0x0, duration=108344.223s, table=0, n_packets=6, n_bytes=1236, idle_age=2304,
  hard_age=65534, priority=1,in_port=9 actions=resubmit(,3)
  cookie=0x0, duration=108351.106s, table=1, n_packets=12, n_bytes=1680, idle_age=2304,
  hard_age=65534, priority=0 actions=resubmit(,2)
  cookie=0x0, duration=108345.552s, table=1, n_packets=476, n_bytes=46648
, idle_age=65534, hard_age=65534, priority=1,dl_vlan=1,dl_src=fa:16:3e:a3:95:c2
  actions=mod_dl_src:fa:16:3f:97:87:a1,resubmit(,2)
  cookie=0x0, duration=108342.096s, table=1, n_packets=1, n_bytes=130, idle_age=65534,
hard_age=65534, priority=1,dl_vlan=2,dl_src=fa:16:3e:cd:50:8d actions=mod_dl_src:fa:16:3f:97:87:a1,
resubmit(,2)
  ... ...
  cookie=0x0, duration=108352.344s, table=2, n_packets=490, n_bytes=48556,
idle_age=2304, hard_age=65534, priority=0,dl_dst=00:00:00:00:00:00/01:00:00:00:00:00
actions=resubmit(,20)
  ...  ...
  cookie=0x0, duration=108343.543s, table=20, n_packets=476, n_bytes=46648, idle_age=65534,
hard_age=65534, priority=2,dl_vlan=1,dl_dst=fa:16:3e:2a:34:19 actions=strip_vlan,
set_tunnel:0x2,output:10
  ... ...

這裏是查看 host 的 MAC 地址。

1
2
3
4
5
6
7
db2 => select * from DVR_HOST_MACS
 
HOST MAC_ADDRESS
---------------------------------------------------------------
test114.sce.ibm.com fa:16:3f:1a:cf:03
test115.sce.ibm.comfa:16:3f:97:87:a1
test116.sce.ibm.com fa:16:3f:ec:09:21

compute1 是經過 gre-0a0b0174 與 compute2 鏈接起來的

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
[root@test115 ~]# ovs-vsctl show
1799e6ea-b3b0-4581-b42e-e1bfd8a5d96d
Bridge br-ex
Port "eth0"
Interface "eth0"
Port br-ex
Interface br-ex
type: internal
Bridge br-tun
fail_mode: secure
Port "gre-0a0b0174"
Interface "gre-0a0b0174"
type: gre
options: {df_default="true", in_key=flow, local_ip="10.11.1.115", out_key= flow,
remote_ip="10.11.1.116"}
Port br-tun
Interface br-tun
type: internal
Port patch-int
Interface patch-int
type: patch
options: {peer=patch-tun}
Port "gre-0a0b0172"
Interface "gre-0a0b0172"
type: gre
options: {df_default="true", in_key=flow, local_ip="10.11.1.115", out_key= flow,
  remote_ip="10.11.1.114"}

下面數據包已經來到了 compute2, 咱們先查看一下 compute2 上的網絡狀況,在 compute2 上,是經過gre-0a0b0173端口與 compute1 傳遞數據流的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
[root@test116 ~]# ovs-vsctl show
590e4ede-0e3c-43c8-ad1c-153c3a101f75
Bridge br-ex
Port "eth0"
Interface "eth0"
Port br-ex
Interface br-ex
type: internal
Bridge br-tun
fail_mode: secure
Port patch-int
Interface patch-int
type: patch
options: {peer=patch-tun}
Port "gre-0a0b0173"
Interface "gre-0a0b0173"
type: gre
options: {df_default="true", in_key=flow, local_ip="10.11.1.116", out_key=flow,
remote_ip="10.11.1.115"}
Port "gre-0a0b0172"
Interface "gre-0a0b0172"
type: gre
options: {df_default="true", in_key=flow, local_ip="10.11.1.116", out_key=flow,
  remote_ip="10.11.1.114"}
Port br-tun
Interface br-tun
type: internal

數據進入 compute2,先進入隧道橋 br-tun。咱們再來查看一下 br-tun 上的端口,它是經過 port 14 傳入 br-tun 的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
[root@test116 ~]# ovs-ofctl show br-tun
OFPT_FEATURES_REPLY (xid=0x2): dpid:00008eab3df3f342
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
  9(patch-int): addr:a2:3b:1e:29:77:9e
config: 0
state: 0
speed: 0 Mbps now, 0 Mbps max
  13(gre-0a0b0172): addr:b6:e7:f7:3f:f6:80
config: 0
state: 0
speed: 0 Mbps now, 0 Mbps max
  14(gre-0a0b0173): addr:02:2c:97:51:29:f7
config: 0
state: 0
speed: 0 Mbps now, 0 Mbps max
  LOCAL(br-tun): addr:8e:ab:3d:f3:f3:42
config: PORT_DOWN
state: LINK_DOWN
speed: 0 Mbps now, 0 Mbps max
OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0

下面查看一下 br-tun 上面的流表

數據先流入 table0,流入端口是 port 14,接着數據轉入 table3,在這裏把隧道轉成了 vlan 號,這裏的 tunnel 就是在 compute1 上的轉換的那個 tunnel 號,接着數據流入 table9, 在這條流上顯示流入地址是 compute1 host 的 MAC 地址,數據從這裏流進 br-int。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
[root@test116 ~]# ovs-ofctl dump-flows br-tun
NXST_FLOW reply (xid=0x4):
  cookie=0x0, duration=1670640.753s, table=0, n_packets=0, n_bytes=0, idle_age=65534,
hard_age=65534, priority=0 actions=drop
  cookie=0x0, duration=353441.887s, table=0, n_packets=29, n_bytes=4904, idle_age=7824,
hard_age=65534, priority=1,in_port=13 actions=resubmit(,3)
  cookie=0x0, duration=352506.309s, table=0, n_packets=2630, n_bytes=142843,
idle_age=65534, hard_age=65534, priority=1,in_port=14 actions=resubmit(,3)
  ... ...
  cookie=0x0, duration=353442.719s, table=3, n_packets=2648, n_bytes=144638, idle_age=7824,
hard_age=65534, priority=1,tun_id=0x2actions=mod_vlan_vid:3,resubmit(,9)
  .... ...
  cookie=0x0, duration=1670637.758s, table=9, n_packets=3003, n_bytes=179397, idle_age=65534,
hard_age=65534, priority=1,dl_src=fa:16:3f:97:87:a1 actions=output:9

... ...

數據包流入 br-int 先進入的是 table0, 數據的流入地址是 compute1 host 的 MAC 地址。接着數據進入 table1, 到達 VM2 的 MAC,流入地址是 192.168.12.1 的 MAC 地址,完成了從 gateway 到 VM 的數據轉發。至此數據包完成了從 VM1 到 VM2 的傳遞,僅僅在 compute 節點之間沒有通過 network 節點。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
[root@test116 ~]# ovs-ofctl dump-flows br-int
NXST_FLOW reply (xid=0x4):
  cookie=0x0, duration=1676015.888s, table=0, n_packets=0, n_bytes=0, idle_age=65534, hard_age=65534,
priority=4,in_port=36,dl_src=fa:16:3f:1a:cf:03 actions=resubmit(,2)
  cookie=0x0, duration=1676015.270s, table=0, n_packets=3003, n_bytes=179397, idle_age=65534,
hard_age=65534, priority=2,in_port=37,dl_src=fa:16:3f:97:87:a1 actions=resubmit(,1)
  ... ...
  cookie=0x0, duration=357883.384s, table=1, n_packets=531, n_bytes=52038, idle_age=65534,
hard_age=65534, priority=4,dl_vlan=3,dl_dst=fa:16:3e:2a:34:19
actions=strip_vlan,mod_dl_src:fa:16:3e:a3:95:c2,output:38
  cookie=0x0, duration=1676017.088s, table=2, n_packets=0, n_bytes=0, idle_age=65534,
hard_age=65534, priority=1 actions=drop
  cookie=0x0, duration=1676017.264s, table=23, n_packets=0, n_bytes=0, idle_age=65534,
hard_age=65534, priority=0 actions=drop

在 compute1 節點的 namespace 上可以獲得 192.168.12.9 的 MAC 地址及狀態。其實在 compute2 節點的 namespace 上可以獲得 192.168.11.14 的 MAC 地址及狀態。這些都保證了兩臺 VM 的可以順利的通訊。

1
2
3
4
5
6
7
[root@test115 ~]# ip netns exec qrouter-a49eee39-7977-4a7f-81e1-dcbf57dbd904 ip nei
fe80::f4ce:f9ff:fe73:ef0d dev qr-c669122c-11 lladdr f6:ce:f9:73:ef:0d STALE
fe80::f816:3eff:fe17:6ba7 dev qr-c669122c-11 lladdr fa:16:3e:17:6b:a7 STALE
192.168.12.10 dev qr-43fad9d6-53 lladdr fa:16:3e:d4:4d:ff PERMANENT
192.168.11.14 dev qr-c669122c-11 lladdr fa:16:3e:17:6b:a7 PERMANENT
192.168.12.9 dev qr-43fad9d6-53 lladdr fa:16:3e:2a:34:19 PERMANENT
192.168.11.13 dev qr-c669122c-11 lladdr fa:16:3e:02:b7:c7 PERMANENT
 

相關主題

相關文章
相關標籤/搜索