openstack核心組件-neutron-理論

neutron 介紹:

傳統的網絡管理方式很大程度上依賴於管理員手工配置和維護各種網絡硬件設備;而云環境下的網絡已經變得非常複雜,特別是在多租戶場景裏,用戶隨時都可能需要創建、修改和刪除網絡,網絡的連通性和隔離不已經太可能通過手工配置來保證了。

如何快速響應業務的需求對網絡管理提出了更高的要求。傳統的網絡管理方式已經很難勝任這項工作,而“軟件定義網絡(software-defined networking, SDN)”所具有的靈活性和自動化優勢使其成爲雲時代網絡管理的主流。

Neutron 的設計目標是實現“網絡即服務(Networking as a Service)”。爲了達到這一目標,在設計上遵循了基於 SDN 實現網絡虛擬化的原則,在實現上充分利用了 Linux 系統上的各種網絡相關的技術。

SDN 模式服務— NeutronSDN( 軟件定義網絡 ), 通過使用它,網絡管理員和雲計算操作員可以通過程序來動態定義虛擬網絡設備。Openstack 網絡中的 SDN 組件就是 Quantum.但因爲版權問題而改名爲Neutron 。

Neutron網絡基本概念

(1)network

network 是一個隔離的二層廣播域。Neutron 支持多種類型的 network,包括 local, flat, VLAN, VxLAN 和 GRE。

local
local 網絡與其他網絡和節點隔離。local 網絡中的 instance 只能與位於同一節點上同一網絡的 instance 通信,local 網絡主要用於單機測試。

flat
flat 網絡是無 vlan tagging 的網絡。flat 網絡中的 instance 能與位於同一網絡的 instance 通信,並且可以跨多個節點。

vlan
vlan 網絡是具有 802.1q tagging 的網絡。vlan 是一個二層的廣播域,同一 vlan 中的 instance 可以通信,不同 vlan 只能通過 router 通信。vlan 網絡可跨節點,是應用最廣泛的網絡類型。

vxlan
vxlan 是基於隧道技術的 overlay 網絡。vxlan 網絡通過唯一的 segmentation ID(也叫 VNI)與其他 vxlan 網絡區分。vxlan 中數據包會通過 VNI 封裝成 UDP 包進行傳輸。因爲二層的包通過封裝在三層傳輸,能夠克服 vlan 和物理網絡基礎設施的限制。

gre
gre 是與 vxlan 類似的一種 overlay 網絡。主要區別在於使用 IP 包而非 UDP 進行封裝。

不同 network 之間在二層上是隔離的。

以 vlan 網絡爲例,network A 和 network B 會分配不同的 VLAN ID,這樣就保證了 network A 中的廣播包不會跑到 network B 中。當然,這裏的隔離是指二層上的隔離,藉助路由器不同 network 是可能在三層上通信的。

network 必須屬於某個 Project( Tenant 租戶),Project 中可以創建多個 network。 network 與 Project 之間是 1對多 關係。

(2)subnet

subnet 是一個 IPv4 或者 IPv6 地址段。instance 的 IP 從 subnet 中分配。每個 subnet 需要定義 IP 地址的範圍和掩碼。

network 與 subnet 是 1對多 關係。一個 subnet 只能屬於某個 network;一個 network 可以有多個 subnet,這些 subnet 可以是不同的 IP 段,但不能重疊。下面的配置是有效的:

network A
subnet A-a: 10.10.1.0/24 {“start”: “10.10.1.1”, “end”: “10.10.1.50”}
subnet A-b: 10.10.2.0/24 {“start”: “10.10.2.1”, “end”: “10.10.2.50”}

但下面的配置則無效,因爲 subnet 有重疊

network A
subnet A-a: 10.10.1.0/24 {“start”: “10.10.1.1”, “end”: “10.10.1.50”}
subnet A-b: 10.10.1.0/24 {“start”: “10.10.1.51”, “end”: “10.10.1.100”}

這裏不是判斷 IP 是否有重疊,而是 subnet 的 CIDR 重疊(都是 10.10.1.0/24)。但是,如果 subnet 在不同的 network 中,CIDR 和 IP 都是可以重疊的,比如

network A subnet A-a: 10.10.1.0/24 {“start”: “10.10.1.1”, “end”: “10.10.1.50”}
network B subnet B-a: 10.10.1.0/24 {“start”: “10.10.1.1”, “end”: “10.10.1.50”}

這裏大家不免會疑惑: 如果上面的IP地址是可以重疊的,那麼就可能存在具有相同 IP 的兩個 instance,這樣會不會衝突? 簡單的回答是:不會!

具體原因: 因爲 Neutron 的 router 是通過 Linux network namespace 實現的。network namespace 是一種網絡的隔離機制。通過它,每個 router 有自己獨立的路由表。上面的配置有兩種結果:

  1. 如果兩個 subnet 是通過同一個 router 路由,根據 router 的配置,只有指定的一個 subnet 可被路由。

  2. 如果上面的兩個 subnet 是通過不同 router 路由,因爲 router 的路由表是獨立的,所以兩個 subnet 都可以被路由。

(3)port

port 可以看做虛擬交換機上的一個端口。port 上定義了 MAC 地址和 IP 地址,當 instance 的虛擬網卡 VIF(Virtual Interface) 綁定到 port 時,port 會將 MAC 和 IP 分配給 VIF。

subnet 與 port 是 1對多 關係。一個 port 必須屬於某個 subnet;一個 subnet 可以有多個 port。

小結:
下面總結了 Project,Network,Subnet,Port 和 VIF 之間關係。
Project 1 : m Network 1 : m Subnet 1 : m Port 1 : 1 VIF m : 1 Instance

Neutron 功能

Neutron 爲整個 OpenStack 環境提供網絡支持,包括二層交換,三層路由,負載均衡,防火牆和 VPN 等。Neutron 提供了一個靈活的框架,通過配置,無論是開源還是商業軟件都可以被用來實現這些功能。

二層交換 Switching

Nova 的 Instance 是通過虛擬交換機連接到虛擬二層網絡的。Neutron 支持多種虛擬交換機,包括 Linux 原生的 Linux Bridge 和 Open vSwitch。 Open vSwitch(OVS)是一個開源的虛擬交換機,它支持標準的管理接口和協議。

利用 Linux Bridge 和 OVS,Neutron 除了可以創建傳統的 VLAN 網絡,還可以創建基於隧道技術的 Overlay 網絡,比如 VxLAN 和 GRE(Linux Bridge 目前只支持 VxLAN)。在後面章節我們會學習如何使用和配置 Linux Bridge 和 Open vSwitch。

三層路由 Routing

Instance 可以配置不同網段的 IP,Neutron 的 router(虛擬路由器)實現 instance 跨網段通信。router 通過 IP forwarding,iptables 等技術來實現路由和 NAT。我們將在後面章節討論如何在 Neutron 中配置 router 來實現 instance 之間,以及與外部網絡的通信。

負載均衡 Load Balancing

Openstack 在 Grizzly 版本第一次引入了 Load-Balancing-as-a-Service(LBaaS),提供了將負載分發到多個 instance 的能力。LBaaS 支持多種負載均衡產品和方案,不同的實現以 Plugin 的形式集成到 Neutron,目前默認的 Plugin 是 HAProxy。我們會在後面章節學習 LBaaS 的使用和配置。

防火牆 Firewalling

Neutron 通過下面兩種方式來保障 instance 和網絡的安全性。

Security Group

通過 iptables 限制進出 instance 的網絡包。

Firewall-as-a-Service

FWaaS,限制進出虛擬路由器的網絡包,也是通過 iptables 實現。

Neutron 優點:
Openstack 中的 SDN 組件架構也屬於可插拔類型。通過各種插件可以管控不同種類的交換機、路由器、防火牆、負載均衡器並實現 firewall as a service 等許多功能。通過軟件來定義的網絡,可以對整個雲計算設施進行更爲精細的掌控。

Neutron 部署方案

方案1:控制節點 + 計算節點:

控制節點:部署的服務包括:neutron server, core plugin 的 agent 和 service plugin 的 agent。

計算節點:部署 core plugin 的agent(ovs agent(控制節點也要部署)),負責提供二層網絡功能。

這裏有幾點需要說明:

  1. core plugin 和 service plugin 已經集成到 neutron server,不需要運行獨立的 plugin 服務。
  2. 控制節點和計算節點都需要部署 core plugin 的 agent,因爲通過該 agent 控制節點與計算節點才能建立二層連接。
  3. 可以部署多個控制節點和計算節點。
    在這裏插入圖片描述

方案2:控制節點 + 網絡節點 + 計算節點

在這個部署方案中,OpenStack 由控制節點,網絡節點和計算節點組成。

控制節點:部署 neutron server 服務。

網絡節點:部署的服務包括:core plugin 的 agent 和 service plugin 的 agent。

計算節點:部署 core plugin 的agent,負責提供二層網絡功能。

這個方案的要點是將所有的 agent 從控制節點分離出來,部署到獨立的網絡節點上。
1,控制節點只負責通過 neutron server 響應 API 請求。

2,由獨立的網絡節點實現數據的交換,路由以及 load balance等高級網絡服務。

3,可以通過增加網絡節點承擔更大的負載。

4,可以部署多個控制節點、網絡節點和計算節點。

該方案特別適合規模較大的 OpenStack 環境。
在這裏插入圖片描述

配置多個網卡區分不同類型的網絡數據

OpenStack 至少包含下面幾類網絡流量
Management
API
VM
External

Management 網絡
用於節點之間 message queue 內部通信以及訪問 database 服務,所有的節點都需要連接到 management 網絡。

API 網絡
OpenStack 各組件通過該網絡向用戶暴露 API 服務。Keystone, Nova, Neutron, Glance, Cinder, Horizon 的 endpoints 均配置在 API 網絡上。通常,管理員也通過 API 網絡 SSH 管理各個節點。

VM 網絡
VM 網絡也叫 tenant 網絡,用於 instance 之間通信。
VM 網絡可以選擇的類型包括 local, flat, vlan, vxlan 和 gre。
VM 網絡由 Neutron 配置和管理。

External 網絡
External 網絡指的是 VM 網絡之外的網絡,該網絡不由 Neutron 管理。 Neutron 可以將 router attach 到 External 網絡,爲 instance 提供訪問外部網絡的能力。 External 網絡可能是企業的 intranet,也可能是 internet。

這幾類網絡只是邏輯上的劃分,物理實現上有非常大的自由度。

我們可以爲每種網絡分配單獨的網卡;也可以多種網絡共同使用一個網卡;爲提高帶寬和硬件冗餘,可以使用 bonding 技術將多個物理網卡綁定成一個邏輯的網卡

neutron 架構

Nuetron 架構

與 OpenStack 的其他服務的設計思路一樣,Neutron 也是採用分佈式架構,由多個組件(子服務)共同對外提供網絡服務。

在這裏插入圖片描述

Neutron 由如下組件構成:

Neutron Server
對外提供 OpenStack 網絡 API,接收請求,並調用 Plugin 處理請求。

Plugin
處理 Neutron Server 發來的請求,維護 OpenStack 邏輯網絡狀態, 並調用 Agent 處理請求。

Agent
處理 Plugin 的請求,負責在 network provider 上真正實現各種網絡功能。

network provider
提供網絡服務的虛擬或物理網絡設備,例如 Linux Bridge,Open vSwitch 或者其他支持 Neutron 的物理交換機。

Queue
Neutron Server,Plugin 和 Agent 之間通過 Messaging Queue 通信和調用。

Database
存放 OpenStack 的網絡狀態信息,包括 Network, Subnet, Port, Router 等。

Neutron 架構非常靈活,層次較多,目的是:

爲了支持各種現有或者將來會出現的優秀網絡技術。

支持分佈式部署,獲得足夠的擴展性。

以創建一個 VLAN100 的 network 爲例,假設 network provider 是 linux bridge, 流程如下:

Neutron Server 接收到創建 network 的請求,通過 Message Queue(RabbitMQ)通知已註冊的 Linux Bridge Plugin。

Plugin 將要創建的 network 的信息(例如名稱、VLAN ID等)保存到數據庫中,並通過 Message Queue 通知運行在各節點上的 Agent。

Agent 收到消息後會在節點上的物理網卡(比如 eth2)上創建 VLAN 設備(比如 eth2.100),並創建 bridge (比如 brqXXX) 橋接 VLAN 設備。

plugin 解決的是 What 的問題,即網絡要配置成什麼樣子?而至於如何配置 How 的工作則交由 agent 完成。

plugin,agent 和 network provider 是配套使用的,比如上例中 network provider 是 linux bridge,那麼就得使用 linux bridge 的 plungin 和 agent;如果 network provider 換成了 OVS 或者物理交換機,plugin 和 agent 也得替換。

plugin 的一個主要的職責是在數據庫中維護 Neutron 網絡的狀態信息,這就造成一個問題:所有 network provider 的 plugin 都要編寫一套非常類似的數據庫訪問代碼。爲了解決這個問題,Neutron 在 Havana 版本實現了一個 ML2(Modular Layer 2)plugin,對 plgin 的功能進行抽象和封裝。有了 ML2 plugin,各種 network provider 無需開發自己的 plugin,只需要針對 ML2 開發相應的 driver 就可以了,工作量和難度都大大減少。ML2 會在後面詳細討論。

plugin 按照功能分爲兩類: core plugin 和 service plugin。core plugin 維護 Neutron 的 netowrk, subnet 和 port 相關資源的信息,與 core plugin 對應的 agent 包括 linux bridge, OVS 等; service plugin 提供 routing, firewall, load balance 等服務,也有相應的 agent。後面也會分別詳細討論。

neutron server 組件詳解:

Neutron server 分層模型

在這裏插入圖片描述

Core API:對外提供管理 network, subnet 和 port 的 RESTful API。

Extension API:對外提供管理 router, load balance, firewall 等資源 的 RESTful API。

Commnon Service:認證和校驗 API 請求。

Neutron Core:Neutron server 的核心處理程序,通過調用相應的 Plugin 處理請求。

Core Plugin API:定義了 Core Plgin 的抽象功能集合,Neutron Core 通過該 API 調用相應的 Core Plgin。

Extension Plugin API:定義了 Service Plgin 的抽象功能集合,Neutron Core 通過該 API 調用相應的 Service Plgin。

Core Plugin:實現了 Core Plugin API,在數據庫中維護 network, subnet 和 port 的狀態,並負責調用相應的 agent 在 network provider 上執行相關操作,比如創建 network。

Service Plugin:實現了 Extension Plugin API,在數據庫中維護 router, load balance, security group 等資源的狀態,並負責調用相應的 agent 在 network provider 上執行相關操作,比如創建 router。

歸納起來,Neutron Server 包括兩部分:

  1. 提供 API 服務。
  2. 運行 Plugin。

即 Neutron Server = API + Plugins

在這裏插入圖片描述

ML2 Core Plugin 詳解

Neutron 是如何支持多種 network provider?

openstack中有兩大常見 Core Plugin: linux bridge plugin 和 open vswitch plugin。
Neutron 可以通過開發不同的 plugin 和 agent 支持不同的網絡技術。這是一種相當開放的架構。不過隨着支持的 network provider 數量的增加,開發人員發現了兩個突出的問題:

  1. 只能在 OpenStack 中使用一種 core plugin,多種 network provider 無法共存。
    只使用一個 core plugin 本身沒有問題。但問題在於傳統的 core plugin 與 core plugin agent 是一一對應的。也就是說,如果選擇了 linux bridge plugin,那麼 linux bridge agent 將是唯一選擇,就必須在 OpenStack 的所有節點上使用 linux bridge 作爲虛擬交換機(即 network provider)。

  2. 不同 plugin 之間存在大量重複代碼,開發新的 plugin 工作量大。
    所有傳統的 core plugin 都需要編寫大量重複和類似的數據庫訪問的代碼,大大增加了 plugin 開發和維護的工作量。

ML2 能解決傳統 core plugin 的問題

Moduler Layer 2(ML2):是 Neutron 在 Havana 版本實現的一個新的 core plugin,用於替代原有的 linux bridge plugin 和 open vswitch plugin。 作爲新一代的 core plugin,提供了一個框架,允許在 OpenStack 網絡中同時使用多種 Layer 2 網絡技術,不同的節點可以使用不同的網絡實現機制。

ML2 對二層網絡進行抽象和建模,引入了 type driver 和 mechansim driver。這兩類 driver 解耦了 Neutron 所支持的網絡類型(type)與訪問這些網絡類型的機制(mechanism),其結果就是使得 ML2 具有非常好的彈性,易於擴展,能夠靈活支持多種 type 和 mechanism。

在這裏插入圖片描述

(1) Type Driver
Neutron 支持的每一種網絡類型都有一個對應的 ML2 type driver。
type driver 負責維護網絡類型的狀態,執行驗證,創建網絡等。 ML2 支持的網絡類型包括 local, flat, vlan, vxlan 和 gre。 我們將在後面章節詳細討論每種 type。

(2) Mechansim Driver
Neutron 支持的每一種網絡機制都有一個對應的 ML2 mechansim driver。
mechanism driver 負責獲取由 type driver 維護的網絡狀態,並確保在相應的網絡設備(物理或虛擬)上正確實現這些狀態。

mechanism driver 有三種類型:

Agent-based
包括 linux bridge, open vswitch 等。

Controller-based
包括 OpenDaylight, VMWare NSX 等。

基於物理交換機
包括 Cisco Nexus, Arista, Mellanox 等。 比如前面那個例子如果換成 Cisco 的 mechanism driver,則會在 Cisco 物理交換機的指定 trunk 端口上添加 vlan100。

Service Plugin / Agent 詳解

Core Plugin/Agent 負責管理核心實體:net, subnet 和 port。而對於更高級的網絡服務,則由 Service Plugin/Agent 管理。

Service Plugin 及其 Agent 提供更豐富的擴展功能,包括路由,load balance,firewall等。

在這裏插入圖片描述

DHCP
dhcp agent 通過 dnsmasq 爲 instance 提供 dhcp 服務。

Routing
l3 agent 可以爲 project(租戶)創建 router,提供 Neutron subnet 之間的路由服務。路由功能默認通過 IPtables 實現。

Firewall
l3 agent 可以在 router 上配置防火牆策略,提供網絡安全防護。另一個與安全相關的功能是 Security Group,也是通過 IPtables 實現。 Firewall 與 Security Group 的區別在於:

1,Firewall 安全策略位於 router,保護的是某個 project 的所有 network。
2,Security Group 安全策略位於 instance,保護的是單個 instance。

Load Balance
Neutron 默認通過 HAProxy 爲 project 中的多個 instance 提供 load balance 服務。

Neutron 架構框架總結

在這裏插入圖片描述

與 OpenStack 其他服務一樣,Neutron 採用的是分佈式架構,包括 Neutorn Server、各種 plugin/agent、database 和 message queue。

  1. Neutron server 接收 api 請求。
  2. plugin/agent 實現請求。
  3. database 保存 neutron 網絡狀態。
  4. message queue 實現組件之間通信。

metadata-agent 之前沒有講到,這裏做個補充:

instance 在啓動時需要訪問 nova-metadata-api 服務獲取 metadata 和 userdata,這些 data 是該 instance 的定製化信息,比如 hostname, ip, public key 等。
但 instance 啓動時並沒有 ip,那如何通過網絡訪問到 nova-metadata-api 服務呢?

答案就是 neutron-metadata-agent 該 agent 讓 instance 能夠通過 dhcp-agent 或者 l3-agent 與 nova-metadata-api 通信

將 Neutron 架構展開
在這裏插入圖片描述

1,Neutron 通過 plugin 和 agent 提供的網絡服務。
2,plugin 位於 Neutron server,包括 core plugin 和 service plugin。
3,agent 位於各個節點,負責實現網絡服務。
4,core plugin 提供 L2 功能,ML2 是推薦的 plugin。
5,使用最廣泛的 L2 agent 是 linux bridage 和 open vswitch。
6,service plugin 和 agent 提供擴展功能,包括 dhcp, routing, load balance, firewall, vpn 等

虛擬機獲取 ip

用 namspace 隔離 DHCP 服務

Neutron 通過 dnsmasq 提供 DHCP 服務,而 dnsmasq 通過 Linux Network Namespace 獨立的爲每個 network 服務隔離
在二層網絡上,VLAN 可以將一個物理交換機分割成幾個獨立的虛擬交換機。類似地,在三層網絡上,Linux network namespace 可以將一個物理三層網絡分割成幾個獨立的虛擬三層網絡。

每個 namespace 都有自己獨立的網絡棧,包括 route table,firewall rule,network interface device 等。

Neutron 通過 namespace 爲每個 network 提供獨立的 DHCP 和路由服務,從而允許租戶創建重疊的網絡。如果
沒有 namespace,網絡就不能重疊,這樣就失去了很多靈活性。

每個 dnsmasq 進程都位於獨立的 namespace, 命名爲 qdhcp-

查看命名空間
#ip netns list

查看詳細信息
#ip netns exec namespace ip a

在這裏插入圖片描述

在這裏插入圖片描述

在這裏插入圖片描述

root namespace:
其實,宿主機本身也有一個 namespace,叫 root namespace,擁有所有物理和虛擬 interface device。物理 interface 只能位於 root namespace。
新創建的 namespace 默認只有一個 loopback device。管理員可以將虛擬 interface,例如 bridge,tap 等設備添加到某個 namespace。

對於 flat_net 的 DHCP 設備 tap19a0ed3d-fe,需要將其放到 namespace qdhcp-7bf09be4-8653-4869-84f0-33494f238627 中,但這樣會帶來一個問題:tap19a0ed3d-fe 將無法直接與 root namespace 中的 bridge 設備 brqf153b42f-c3 連接。
Neutron 使用 veth pair 解決了這個問題。
veth pair 是一種成對出現的特殊網絡設備,它們象一根虛擬的網線,可用於連接兩個 namespace。向 veth pair 一端輸入數據,在另一端就能讀到此數據。
tap19a0ed3d-fe 與 ns-19a0ed3d-fe 就是一對 veth pair,它們將 qdhcp-f153b42f-c3a1-4b6c-8865-c09b5b2aa274 連接到 brqf153b42f-c3。
在這裏插入圖片描述

獲取 dhcp IP 過程分析

在創建 instance 時,Neutron 會爲其分配一個 port,裏面包含了 MAC 和 IP 地址信息。這些信息會同步更新到 dnsmasq 的 host 文件。
在這裏插入圖片描述

同時 nova-compute 會設置虛機 VIF 的 MAC 地址。

在這裏插入圖片描述

instance 獲取 IP 的過程如下:

  1. vm 開機啓動,發出 DHCPDISCOVER 廣播,該廣播消息在整個 net 中都可以被收到。

  2. 廣播到達 veth tap19a0ed3d-fe(dhcp端口),然後傳送給 veth pair 的另一端 ns-19a0ed3d-fe。dnsmasq 在它上面監聽,dnsmasq 檢查其 host 文件,發現有對應項,於是dnsmasq 以 DHCPOFFER 消息將 IP、子網掩碼、地址租用期限等信息發送給 vm。

  3. vm 發送 DHCPREQUEST 消息確認接受此 DHCPOFFER。

  4. dnsmasq 發送確認消息 DHCPACK,整個過程結束。

VXLAN簡介

overlay network概念

overlay network 是指建立在其他網絡上的網絡。overlay network 中的節點可以看作通過虛擬(或邏輯)鏈路連接起來的。overlay network 在底層可能由若干物理鏈路組成,但對於節點,不需要關心這些底層實現。

例如 P2P 網絡就是 overlay network,隧道也是。vxlan 和 gre 都是基於隧道技術實現的,它們也都是 overlay network。

VXLAN簡介

VXLAN 爲 Virtual eXtensible Local Area Network。正如名字所描述的,VXLAN 提供與 VLAN 相同的以太網二層服務,但擁有更強的擴展性和靈活性。與 VLAN 相比,
VXLAN 有下面幾個優勢:

  1. 支持更多的二層網段。
    VLAN 使用 12-bit 標記 VLAN ID,最多支持 4094 個 VLAN,這對大型雲部署會成爲瓶頸。VXLAN 的 ID (VNI 或者 VNID)則用 24-bit 標記,支持 16777216 個二層網段。
  2. 能更好地利用已有的網絡路徑。
    VLAN 使用 Spanning Tree Protocol 避免環路,這會導致有一半的網絡路徑被 block 掉。VXLAN 的數據包是封裝到 UDP 通過三層傳輸和轉發的,可以使用所有的路徑。
  3. 避免物理交換機 MAC 表耗盡。
    由於採用隧道機制,TOR (Top on Rack) 交換機無需在 MAC 表中記錄虛擬機的信息。

VXLAN 封裝和包格式:
VXLAN 是將二層建立在三層上的網絡。通過將二層數據封裝到 UDP 的方式來擴展數據中心的二層網段數量。
VXLAN 是一種在現有物理網絡設施中支持大規模多租戶網絡環境的解決方案。VXLAN 的傳輸協議是 IP + UDP。
VXLAN 定義了一個 MAC-in-UDP 的封裝格式。在原始的 Layer 2 網絡包前加上 VXLAN header,然後放到 UDP 和 IP 包中。通過 MAC-in-UDP 封裝,VXLAN 能夠在 Layer 3 網絡上建立起了一條 Layer 2 的隧道。

Open vSwitch:
在這裏插入圖片描述

Open vSwitch 中的網絡設備:
br-ex:連接外部(external)網絡的網橋。
br-int:集成(integration)網橋,所有 instance 的虛擬網卡和其他虛擬網絡設備都將連接到該網橋。
br-tun:隧道(tunnel)網橋,基於隧道技術的 VxLAN 和 GRE 網絡將使用該網橋進行通信。
tap interface:命名爲 tapXXXX。
linux bridge:命名爲 qbrXXXX。
veth pair:命名爲 qvbXXXX, qvoXXXX
OVS integration bridge:命名爲 br-int。
OVS patch ports:命名爲 int-br-ethX 和 phy-br-ethX(X 爲 interface 的序號)。
OVS provider bridge:命名爲 br-ethX(X 爲 interface 的序號)。
物理 interface:命名爲 ethX(X 爲 interface 的序號)。
OVS tunnel bridge:命名爲 br-tun。

三層網絡介紹

虛擬機訪問外網

(1)虛擬機中訪問一個外網地址,並用 traceroute 命令跟蹤路由查看
(2)根據網絡拓撲,由於虛機訪問外網要經過本網段的網關,然後經過路由的外網接口轉發出去,到達目標ip
(3)查看路由命名空間的網絡配置,查到路由連接外網的端口和ip
在這裏插入圖片描述

(4)查看路由iptables NAT 轉發規則,記錄對私網做的SNAT
在這裏插入圖片描述

(5)驗證:
在虛機 ping外網 時, 可以通過 tcpdump 分別觀察 router 兩個 interface 的 icmp 數據包來驗證 SNAT 的行爲:

#ip netns exec qrouter-176bd7e0-6427-46a5-906a-be6a373a29a1 tcpdump -i qg-8df29d32-d6 -n icmp

外網訪問虛機——floating ip原理

SNAT 讓 instance 能夠直接訪問外網,但外網還不能直接訪問 instance。因爲 instance 沒有外網 IP。這裏 “直接訪問 instance” 是指通信連接由外網發起,例如從外網 SSH 實例。

(1)首先將實例綁定浮動 ip, floating IP 是配置在 router 的外網 interface 上的,再查看 router 的 interface 配置
(2)在實例中ping外網地址,在路由的qr-7b56f58b-b5 接口上,實例訪問外網ip,外網ip將數據包轉發回實例ip;但在路由的qg-8df29d32-d6 接口上,始終是通過 floating IP 與外網通信。
(3) 原因是在路由中iptables做了DNA T(基於目的地址轉發),查看 router 的 NAT 規則

當 router 接收到從外網發來的包,如果目的地址是 floating IP ,將目的地址修改爲實例的 IP 。這樣外網的包就能送達到實例;
當實例發送數據到外網,源地址 將被修改爲 floating IP 。

在這裏插入圖片描述

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章