2. 程式人生 > >OpenStack 網路總結之：理解GRE隧道的工作流程

OpenStack 網路總結之：理解GRE隧道的工作流程

阿新 • • 發佈：2018-12-24

文章背景

Openstack的網路配置複雜多樣，本文講述的流程只符合以下場景:

  • 網路型別為GRE隧道 
  • 單獨的網路控制節點;

流程介紹

下面是簡單的流程圖


下面是各個部分包含的PORT

 

下面章節的名稱中會包含圖中關鍵點的編號

計算節點:例項網路 (A,B,C)

 所有發出的資料包都是從例項的eth0開始的，它連線到tap裝置，tap裝置連線到Linux的網橋裝置qbr。從圖中可以看出tap裝置沒有直接連線到整合網橋br-int,而是通過qbr中轉了一下，這時為什麼了？主要是因為OVS的網橋br-int沒有設定iptables規則的功能，但OpenStack又想要(或必須)提供安全組服務，那麼就藉助了Linux Bridge的功能。雖說OVS的br-int網橋和LinuxBridge都是二層橋，但是為了功能相互彌補，就同時出現了。

通過在計算節點上檢視防火牆的規則，可以發現很多規則都是和tap裝置相關的

[plain] view plain copy  print?
  1. # iptables -S | greptap7c7ae61e-05  
  2. -A quantum-openvswi-FORWARD -m physdev --physdev-out tap7c7ae61e-05--physdev-is-bridged -j quantum-openvswi-sg-chain  
  3. -A quantum-openvswi-FORWARD -m physdev --physdev-in tap7c7ae61e-05--physdev-is-bridged -j quantum-openvswi-sg-chain  
  4. -A quantum-openvswi-INPUT -m physdev --physdev-in tap7c7ae61e-05--physdev-is-bridged -j quantum-openvswi-o7c7ae61e-0  
  5. -A quantum-openvswi-sg-chain -m physdev --physdev-out tap7c7ae61e-05--physdev-is-bridged -j quantum-openvswi-i7c7ae61e-0  
  6. -A quantum-openvswi-sg-chain -m physdev --physdev-in tap7c7ae61e-05--physdev-is-bridged -j quantum-openvswi-o7c7ae61e-0    

quantum-openvswi-sg-chain是由neutron-managed security groups產生的，quantum-openvswi-o7c7ae61e-0主要用來控制例項發出的outbound訊息規則

，quantum-openvswi-i7c7ae61e-0chain 主要用來控制從外部到例項的inbound訊息 規則

計算節點: 整合網橋br-int (D,E)

整合網橋(br-int)負責執行從例項接受或發出的流量中vlan 標示的拆封工作，此時結算節點上br-int的情況應該類似於

[plain] view plain copy  print?
  1. #ovs-vsctl show  
  2. Bridge br-int  
  3.     Port"qvo7c7ae61e-05"  
  4.         tag: 1  
  5.         Interface "qvo7c7ae61e-05"  
  6.     Port patch-tun  
  7.         Interface patch-tun  
  8.             type: patch  
  9.             options:{peer=patch-int}  
  10.     Port br-int  
  11.         Interface br-int  
  12.             type: internal  

介面qvo7c7ae61e-05與qvb7c7ae61e-05是一對介面，它們負責將Linux網橋的流量傳輸到br-int上，qvo上的tag:1是一個接入埠，這個埠被掛到了VLAN1上，從例項發出的流量會被賦上VLAN ID 1的標示，發往該例項的流量也先被拆掉VLAN 1的標示,每個不同的網路會被賦予不同的VLAN ID.

介面 patch-tun把br-int連線到隧道橋( br-tun)上.

計算節點: 隧道橋 br-tun(F,G)

隧道橋主要負責把br-int中帶有vlan標示的流量轉換到GRE隧道中，實際的轉換工作主要是由br-tun中OpenFlow規則來完成的，在建立例項之前openflow的規則大概如下：

[plain] view plain copy  print?
  1. #ovs-ofctl dump-flows br-tun  
  2. NXST_FLOW reply (xid=0x4):  
  3.  cookie=0x0, duration=871.283s, table=0,n_packets=4, n_bytes=300, idle_age=862, priority=1 actions=drop  

目前只有一條規則，這條規則會讓br-tun丟掉所有的流量，當你在計算節點上啟動一個例項後，openflow的規則會被修改成下面的樣子：

[plain] view plain copy  print?
  1. #ovs-ofctl dump-flows br-run  
  2. NXST_FLOW reply (xid=0x4):  
  3.  cookie=0x0, duration=422.158s, table=0,n_packets=2, n_bytes=120, idle_age=55,priority=3,tun_id=0x2,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 actions=mod_vlan_vid:1,output:1  
  4.  cookie=0x0, duration=421.948s, table=0,n_packets=64, n_bytes=8337, idle_age=31,priority=3,tun_id=0x2,dl_dst=fa:16:3e:dd:c1:62 actions=mod_vlan_vid:1,NORMAL  
  5.  cookie=0x0, duration=422.357s, table=0,n_packets=82, n_bytes=10443, idle_age=31, priority=4,in_port=1,dl_vlan=1actions=set_tunnel:0x2,NORMAL  
  6.  cookie=0x0, duration=1502.657s, table=0,n_packets=8, n_bytes=596, idle_age=423, priority=1 actions=drop  

通常，這些規則負責對映br-int使用的VLAN ID 1，以及GRE 隧道使用的tunnel id2

第一條規則

[plain] view plain copy  print?
  1. cookie=0x0, duration=422.158s, table=0,n_packets=2, n_bytes=120, idle_age=55,priority=3,tun_id=0x2,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00actions=mod_vlan_vid:1,output:1  

匹配的條件為tunnel id2 (tun_id=0x2), VLAN ID 1 (actions=mod_vlan_vid:1),以及從埠1發出的流量

通過使用ovs-ofctlshow br-tun 可以看出埠1是patch-int

[plain] view plain copy  print?
  1. #ovs-ofctl show br-tun  
  2. OFPT_FEATURES_REPLY (xid=0x2): dpid:0000068df4e44a49  
  3. n_tables:254, n_buffers:256  
  4. capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATSARP_MATCH_IP  
  5. actions: OUTPUT SET_VLAN_VID SET_VLAN_PCP STRIP_VLAN SET_DL_SRC SET_DL_DSTSET_NW_SRC SET_NW_DST SET_NW_TOS SET_TP_SRC SET_TP_DST ENQUEUE  
  6.  1(patch-int):addr:46:3d:59:17:df:62  
  7.      config:     0  
  8.      state:      0  
  9.      speed: 0 Mbps now, 0 Mbps max  
  10.  2(gre-2):addr:a2:5f:a1:92:29:02  
  11.      config:     0  
  12.      state:      0  
  13.      speed: 0 Mbps now, 0 Mbpsmax  
  14.  LOCAL(br-tun):addr:06:8d:f4:e4:4a:49  
  15.      config:     0  
  16.      state:      0  
  17.      speed: 0 Mbps now, 0 Mbpsmax  
  18. OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0  

有一條規則是

[plain] view plain copy  print?
  1. cookie=0x0, duration=422.357s, table=0,n_packets=82, n_bytes=10443, idle_age=31, priority=4,in_port=1,dl_vlan=1actions=set_tunnel:0x2,NORMAL  


匹配的條件是(in_port=1) ， VLAN ID 1 (dl_vlan=1) ，如果匹配就在發出GRE隧道之前，設定 tunnel id 為 2 (actions=set_tunnel:0x2) .

網路節點:隧道橋(br-tun) (H,I)

當流量通過連線到br-tun的GRE隧道到達網路節點,該節點上隧道橋的flowtable與計算節點上的非常相似

[plain] view plain copy  print?
  1. # ovs-ofctl dump-flowsbr-tun  
  2. NXST_FLOW reply (xid=0x4):  
  3.  cookie=0x0, duration=1239.229s, table=0,n_packets=23, n_bytes=4246, idle_age=15,priority=3,tun_id=0x2,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 actions=mod_vlan_vid:1,output:1  
  4.  cookie=0x0, duration=524.477s, table=0,n_packets=15, n_bytes=3498, idle_age=10,priority=3,tun_id=0x2,dl_dst=fa:16:3e:83:69:cc actions=mod_vlan_vid:1,NORMAL  
  5.  cookie=0x0, duration=1239.157s, table=0,n_packets=50, n_bytes=4565, idle_age=148,priority=3,tun_id=0x2,dl_dst=fa:16:3e:aa:99:3c actions=mod_vlan_vid:1,NORMAL  
  6.  cookie=0x0, duration=1239.304s, table=0,n_packets=76, n_bytes=9419, idle_age=10, priority=4,in_port=1,dl_vlan=1actions=set_tunnel:0x2,NORMAL  
  7.  cookie=0x0, duration=1527.016s, table=0,n_packets=12, n_bytes=880, idle_age=527, priority=1 actions=drop  
 

和在計算節點上一樣，第一條規則對映tunnel ID 2 上的多路廣播流量到VLAN 1

As on thecompute host, the first rule maps multicast traffic on tunnel ID 2 to VLAN 1.

第二條規則

[plain] view plain copy  print?
  1. cookie=0x0, duration=524.477s, table=0,n_packets=15, n_bytes=3498, idle_age=10,priority=3,tun_id=0x2,dl_dst=fa:16:3e:83:69:cc actions=mod_vlan_vid:1,NORMAL  

流量在隧道上轉向fa:16:3e:83:69:cc，這是一個執行在網路命令空間的dnsmasq 程序

...matchestraffic on the tunnel destined for the DHCP server at fa:16:3e:83:69:cc. Thisis a dnsmasq process running inside a network namespace, the details of whichwe will examine shortly.

下一條規則

[plain] view plain copy  print?
  1. cookie=0x0, duration=1239.157s, table=0,n_packets=50, n_bytes=4565, idle_age=148,priority=3,tun_id=0x2,dl_dst=fa:16:3e:aa:99:3c actions=mod_vlan_vid:1,NORMAL  


匹配的流量在tunnel ID2，轉向fa:16:3e:aa:99:3c上的router,這個router在另外一個網路名稱空間

...matchestraffic on tunnel ID 2 destined for the router at fa:16:3e:aa:99:3c, which isan interface in another network namespace.

下一條規則

[plain] view plain copy  print?
  1. cookie=0x0, duration=1239.304s, table=0,n_packets=76, n_bytes=9419, idle_age=10, priority=4,in_port=1,dl_vlan=1actions=set_tunnel:0x2,NORMAL  

將tunnel id 設定為2

網路節點:整合橋br-int(IJ)

該橋負責將例項連線到網路服務上，例如路由或者是DHCP服務

[plain] view plain copy  print?
  1. # ovs-vsctl show  
  2. Bridge br-int  
  3.     Port patch-tun  
  4.         Interface patch-tun  
  5.             type: patch  
  6.             options:{peer=patch-int}  
  7.     Port"tapf14c598d-98"  
  8.         tag: 1  
  9.         Interface"tapf14c598d-98"  
  10.     Port br-int  
  11.         Interface br-int  
  12.             type: internal  
  13.     Port"tapc2d7dd02-56"  
  14.         tag: 1  
  15.         Interface"tapc2d7dd02-56"  


Br-int通過使用patch介面patch-tun連線到br-tun

Network host: DHCP server (O,P)

每一個啟動DHCP的網路都會有一個DHCP服務執行在網路節點上，DHCP服務是一個執行在網路名稱空間的dnsmasq例項(網路名稱空間（network namespace）是一個Linux kernel裝置，該裝置允許建立一個獨立於宿主機的網路棧（棧中可以包含介面，路由表，防火牆規則等）)

可以通過ip netns的命令檢視網路名稱空間

[plain] view plain copy  print?
  1. # ipnetns  
  2. qdhcp-88b1609c-68e0-49ca-a658-f1edff54a264  
  3. qrouter-2d214fde-293c-4d64-8062-797f80ae2d8f  

以qdhcp開頭的記錄是私有網路的名稱空間，可以通過執行neutron net-list查到與之對應的網路記錄

以qrouter開頭的記錄是路由的名稱空間，可以通過執行neutron router-list 查到對應的路由記錄

可以通過使用ip netnsexec command 的方式在一個名稱空間內執行一些命令,例如想要檢視DHCP名稱空間的介面配置

[plain] view plain copy<div style="position: absolute; left: 489px; top: 6137px; width: 27px; height: 15px

相關推薦

OpenStack 網路總結之：理解GRE隧道的工作流程

文章背景 Openstack的網路配置複雜多樣，本文講述的流程只符合以下場景: 網路型別為GRE隧道 單獨的網路控制節點; 流程介紹 下面是簡單的流程圖 下面是各個部分包含的PORT   下面章節的名稱中會包含圖中關鍵點的編號 計算節點:例項網路 (A,B,C)  所有發出的資料包都是從例

Openstack儲存總結之：使用Ceph叢集作為後端統一儲存

 前提條件 一個可以正常執行的Ceph叢集，該叢集採用ceph-deploy建立，dataprovider為管理節點，包括三個MON,四個MON 以及Openstack叢集，其中Openstack叢集假設Cinder,Glance都是安裝在叫做controllernod

路由技術之 VPN家族 GRE隧道

vpn gre路由技術之 VPN家族 GRE隧道1.GRE介紹VPN 技術中的一種，稱為通用路由交換協議能夠實現互聯網中，兩個內網網段互通2.實驗目的實現類似上海公司 和 北京公司的內網互通3.實驗拓撲4.實驗配置信息ip 信息統計R1 上海路由器gig0/1 公網接口10.1.1.1 gig0/0 內網接口

網路程式設計之：TCP伺服器的簡單實現

說到TCP伺服器，就不得不提socket程式設計，我們知道，在TCP/IP協議中,“IP地址+TCP或UDP埠號”唯一標識⽹絡通訊中的唯一一個程序,“IP地址+埠號”就稱為socket。 在TCP協

計算機網路總結之運輸層

運輸層 （1），基本術語 程序（process）： 指計算機中正在執行的程式實體 應用程序互相通訊： 一臺主機的程序和另一臺主機中的一個程序交換資料的過程（另外注意通訊真正的端點不是主機而是主機中的程序，也就是說端到端的通訊是應用程序之間的通訊

vue學習總結四：理解vue-router

我們知道vue專案都是單頁面應用，只有一個index.html檔案，但是頁面之前的跳轉是依賴什麼呢，vue提供了一個vue-router外掛幫助我們實現頁面之間的相互跳轉，接下來我會重新改造一下之前的那個yourprojectname專案，新建四個頁面:主頁---->列

Memcached使用總結之：Memcache知識點梳理

操作流程：1、檢查客戶端的請求資料是否在memcached中，如有，直接把請求資料返回，不再對資料庫進行任何操作，路徑操作為①②③⑦。2、如果請求的資料不在memcached中，就去查資料庫，把從資料庫中獲取的資料返回給客戶端，同時把資料快取一份到memcached中（memcached客戶端不負責，需要程式

Ceph實踐總結之：Centos 下RBD塊裝置客戶端的配置

    如果客戶端需要重啟，需要將掛載目錄先解除安裝，重啟之後再重新執行rbd map,以及mount 的操作，否則系統在重啟的過程中會被卡在"Umounting file system"這個操作上。解除安裝命令如下：

openstack網路模式之vlan分析

 openstack neutron中定義了四種網路模式：# tenant_network_type = local# tenant_network_type = vlan   # Example: tenant_network_type = gre# Example: te

【網路程式設計】深入理解TCP的工作機制詳解

TCP的特點及其目的 為了通過IP資料報實現可靠性傳輸，需要考慮很多事情，例如資料的破壞、丟包、重複以及分片順序混亂等，TCP通過校驗和、序列號、確認應答、重發控制、連線管理以及視窗控制等機制等實現可靠性傳輸。 通過序列號與確認應答提高可靠性 在TCP中，當傳送端的

vue學習總結二：專案前期準備工作

當我們構建完專案之後不要急於開始寫程式碼，一些準備工作還是必須要先完成的，比如：因為我們是做的移動端單頁面的專案，會存在300ms的點選延遲問題，改怎麼解決？由於各遊覽器廠商對不同html標籤的樣式具有不同的初始化定義，因此我們要做到遊覽器相容性的話就必須要統一初始化一個樣式

安卓專案實戰之：最實用的載入中、無網路、無資料、出錯四種情況切換庫的使用總結

效果圖 錄出來的效果不是很好，真機上展示效果還算完美。 如圖所示該效果的實現依賴三個庫： 1，頂部Tab導航：比TabLayout功能更強大的FlycoTabLayout，具體使用檢視本人之前部落格：安卓專案實戰之：FlycoTabLayout和FlycoRoundView的介紹及

深入理解Neutron -- OpenStack網路實現：VLAN模式

網路節點 類似GRE模式下，br-eth1收到到達的網包，int-br-eth1和phy-br-eth1上分別進行vlan轉換，保證到達br-int上的網包都是帶有內部vlan tag，到達br-eth1上的都是帶有外部vlan tag。br-ex則完成到OpenStack以外網路的連線。檢視網橋資訊，包

四：OVS+GRE之網路節點

關於Neutron上的三種Agent的作用： Neutron-OVS-Agent：從OVS-Plugin上接收tunnel和tunnel flow的配置，驅動OVS來建立GRE Tunnel Neutron-DHCP-Agent：為每一個配置了DHCP的網路/子網配置dnsmasq，也負責

項目總結二：模塊管理之requireJS

pig 所有 依賴 yui 一個 ava archive 狀況 oot 項目開發前期，對究竟用requireJS 還是sea.js 進行討論，最後采用requireJS，但是後期遇到了問題——當谷歌地圖不能加載時，整個頁面卡死的狀況。 requirejs 的作用： 防止j

Lucene學習總結之二：Lucene的總體架構

api 要點 iter 不同 blank 應用 文件 score image Lucene總的來說是： 一個高效的，可擴展的，全文檢索庫。 全部用Java實現，無須配置。 僅支持純文本文件的索引(Indexing)和搜索(Search)。 不負責由其他格式的文件抽取純文

iptables詳解（13）：iptables動作總結之二

定義 行動 在外 nat配置 centos6 外部 重復 image 理論 概述 閱讀這篇文章需要站在前文的基礎上，如果你在閱讀時遇到障礙，請參考之前的文章。 前文中，我們已經了解了如下動作 ACCEPT、DROP、REJECT、LOG 今天，我們來認識幾個新動作，它們

Learning-Python【29】：網路程式設計之粘包

粘包問題 　　上一篇部落格遺留了一個問題，在接收的最大位元組數設定為 1024 時，當接收的結果大於1024，再執行下一條命令時還是會返回上一條命令未執行完成的結果。這就是粘包問題。 　　因為TCP協議又叫流式協議，每次傳送給客戶端的資料實際上是傳送到客戶端所在作業系統的快取上，客戶端就是一個應用程式，需

Java基礎總結之網路程式設計

網路程式設計：用Java語言實現計算機間資料的資訊傳遞和資源共享。 網路模型：七層：（從上至下）分別是：應用層、表示層、會話層、傳輸層、網路層、資料鏈路層、物理層。 網路程式設計的三要素：ip、埠、協議 ip：網路中計算機的唯一標識。Ip在計算機底層是由二進位制所表示的，但是為了方便，人

week7：網路程式設計之基礎

一、OSI模型 二、網路通訊要素 2.1、IP地址 2.2、埠號 2.3、傳輸協議 三、socket程式設計 socket即是一種特殊的檔案，一些socket函式就是對其進行的操作（讀/寫IO、開啟、關閉)。 Socket 是任何一種計算機網路通訊中最基礎的內容。例如當你