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 網絡的抗單點失敗的能力。
本文主要講解的是 E-W 方向上的虛擬機通信情況。
非 DVR 和 DVR 情況下，網絡節點流量對比
這是在有相同數量的虛機的情況下的對比。
- 非 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 作為環境的網絡類型。我們這里的環境情況如下：
網絡節點是 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
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
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 的情況，數據包是直接在兩個計算節點上傳遞。
配置 DVR
配置文件
在網絡節點和計算節點配置 DVR:
- 網絡節點：因為 DVR 是屬于 l3-agent 的功能,并依賴于 l3-agent，所以我們在這里的改動應該默認為環境上的 l3-agent 是可以工作的。具體配置如下：
修改對應文件：
neutron.conf : router_distributed = True
l3_agent.ini : agent_mode = dvr_snat
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 |
相關主題
轉載于:https://www.cnblogs.com/zx-bob-123/p/8809461.html
總結
以上是生活随笔為你收集整理的neutron DVR的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： hive 的udf 函数使用
- 下一篇： 关键词 - SEO中最重要的项目