本系列會分析OpenStack 的高可用性（HA）概念和解決方案：
（2）Neutron L3 Agent HA - VRRP （虛擬路由冗余協議）
（3）Neutron L3 Agent HA - DVR （分布式虛機路由器）
（4）Pacemaker 和 OpenStack Resource Agent （RA）
（5）RabbitMQ HA
（6）MySQL HA
Neutron 作為 OpenStack 一個基礎性關鍵服務，高可用性（HA）和擴展性是它的基本需求之一。對 neutron server 來說，因為它是無狀態的，我們可以使用負載均衡器（Load Balancer）比如 HAProxy 來實現其 HA 和擴展性；對於 Neutron L3 Agent 來說，一個帶外（Out-of-band）的 HA 實現方案可以使用 PeaceMaker，但是這會大大增加系統的復雜性，另一個就是之前介紹的 VRRP，但是它也存在不少問題：（1）需要額外的硬件來組成 VRRP 組，這會帶來成本增加（2）它無法解決擴展性問題，東-西和南-北網絡流量都需要經過活動的 VRRP Router。而 Juno 中引入的 DVR 功能正是用來解決這兩點不足的。
1.基礎知識
1.1 路由 （Routing）
1.1.1 路由策略 （使用 ip rule 命令操作路由策略數據庫）
基於策略的路由比傳統路由在功能上更強大，使用更靈活，它使網絡管理員不僅能夠根據目的地址而且能夠根據報文大小、應用或IP源地址等屬性來選擇轉發路徑。
- Usage: ip rule [ list | add | del ] SELECTOR ACTION （add 添加；del 刪除； llist 列表）
- SELECTOR := [ from PREFIX 數據包源地址] [ to PREFIX 數據包目的地址] [ tos TOS 服務類型][ dev STRING 物理接口] [ pref NUMBER ] [fwmark MARK iptables 標簽]
- ACTION := [ table TABLE_ID 指定所使用的路由表] [ nat ADDRESS 網絡地址轉換][ prohibit 丟棄該表| reject 拒絕該包| unreachable 丟棄該包]
- [ flowid CLASSID ]
- TABLE_ID := [ local | main | default | new | NUMBER ]
例子：
- ip rule add from 192.203.80/24 table inr.ruhep prio 220 通過路由表 inr.ruhep 路由來自源地址為192.203.80/24的數據包
- ip rule add from 193.233.7.83 nat 192.203.80.144 table 1 prio 320 把源地址為193.233.7.83的數據報的源地址轉換為192.203.80.144，並通過表1進行路由
在 Linux 系統啟動時，內核會為路由策略數據庫配置三條缺省的規則：
- 0 匹配任何條件 查詢路由表local(ID 255) 路由表local是一個特殊的路由表，包含對於本地和廣播地址的高優先級控制路由。rule 0非常特殊，不能被刪除或者覆蓋。
- 32766 匹配任何條件 查詢路由表main(ID 254) 路由表main(ID 254)是一個通常的表，包含所有的無策略路由。系統管理員可以刪除或者使用另外的規則覆蓋這條規則。
- 32767 匹配任何條件 查詢路由表default(ID 253) 路由表default(ID 253)是一個空表，它是為一些后續處理保留的。對於前面的缺省策略沒有匹配到的數據包，系統使用這個策略進行處理。這個規則也可以刪除。
不要混淆路由表和策略：規則指向路由表，多個規則可以引用一個路由表，而且某些路由表可以沒有策略指向它。如果系統管理員刪除了指向某個路由表的所有規則，這個表就沒有用了，但是仍然存在，直到里面的所有路由都被刪除，它才會消失。
（資料來源）
1.1.2 路由表 （使用 ip route 命令操作靜態路由表）
所謂路由表，指的是路由器或者其他互聯網網絡設備上存儲的表，該表中存有到達特定網絡終端的路徑，在某些情況下，還有一些與這些路徑相關的度量。路由器的主要工作就是為經過路由器的每個數據包尋找一條最佳的傳輸路徑，並將該數據有效地傳送到目的站點。由此可見，選擇最佳路徑的策略即路由算法是路由器的關鍵所在。為了完成這項工作，在路由器中保存着各種傳輸路徑的相關數據——路由表（Routing Table），供路由選擇時使用，表中包含的信息決定了數據轉發的策略。打個比方，路由表就像我們平時使用的地圖一樣，標識着各種路線，路由表中保存着子網的標志信息、網上路由器的個數和下一個路由器的名字等內容。路由表根據其建立的方法，可以分為動態路由表和靜態路由表。
linux 系統中，可以自定義從 1－252個路由表，其中，linux系統維護了4個路由表：
- 0#表： 系統保留表
- 253#表： defulte table 沒特別指定的默認路由都放在改表
- 254#表： main table 沒指明路由表的所有路由放在該表
- 255#表： locale table 保存本地接口地址，廣播地址、NAT地址 由系統維護，用戶不得更改
路由表的查看可有以下二種方法：
- ip route list table table_number
- ip route list table table_name
路由表序號和表名的對應關系在 /etc/iproute2/rt_tables 文件中，可手動編輯。路由表添加完畢即時生效，下面為實例：
- ip route add default via 192.168.1.1 table 1 在一號表中添加默認路由為192.168.1.1
- ip route add 192.168.0.0/24 via 192.168.1.2 table 1 在一號表中添加一條到192.168.0.0網段的路由為192.168.1.2
以下面的路由表為例：
Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.123.254 192.168.123.88 1 #缺省路由，目的地址不在本路由表中的數據包，經過本機的 192.168.123.88 接口發到下一個路由器 192.168.123.254
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 #發給本機的網絡包
192.168.123.0 255.255.255.0 192.168.123.68 192.168.123.68 1 #直連路由。目的地址為 192.168.123.0/24 的包發到本機 192.168.123.88 接口
192.168.123.88 255.255.255.255 127.0.0.1 127.0.0.1 1 #目的地址為 192.168.123.88的包是發給本機的包
192.168.123.255 255.255.255.255 192.168.123.88 192.168.123.88 1 #廣播包的網段是 192.168.123.0/24，經過 192.168.123.88 接口發出去
224.0.0.0 224.0.0.0 192.168.123.88 192.168.123.88 1 #多播包，經過 192.168.123.88 接口發出去
255.255.255.255 255.255.255.255 192.168.123.68 192.168.123.68 1 #全網廣播包
Default Gateway: 192.168.123.254
各字段說明：
- destination：目的網段
- mask：與網絡目標地址相關聯的網掩碼（又稱之為子網掩碼）。子網掩碼對於 IP 網絡地址可以是一適當的子網掩碼，對於主機路由是 255.255.255.255 ，對於默認路由是 0.0.0.0。如果忽略，則使用子網掩碼 255.255.255.255。定義路由時由於目標地址和子網掩碼之間的關系，目標地址不能比它對應的子網掩碼更為詳細。換句話說，如果子網掩碼的一位是 0，則目標地址中的對應位就不能設置為 1。
- interface：到達該目的地的本路由器的出口ip
- gateway： 下一跳路由器入口的 ip，路由器通過 interface 和 gateway 定義一調到下一個路由器的鏈路。通常情況下，interface 和 gateway 是同一網段的metric 跳數，該條路由記錄的質量，一般情況下，如果有多條到達相同目的地的路由記錄，路由器會采用metric值小的那條路由
根據子網掩碼，可以將路由分為三種類型：
- 主機路由：機路由是路由選擇表中指向單個IP地址或主機名的路由記錄。主機路由的Flags字段為H。
Destination Gateway Genmask Flags Metric Ref Use Iface ----------- ------- ------- ----- ------ --- --- ----- 10.0.0.10 192.168.1.1 255.255.255.255 UH 0 0 0 eth0
- 網絡路由：網絡路由是代表主機可以到達的網絡。網絡路由的Flags字段為N。例如，在下面的示例中，本地主機將發送到網絡192.19.12的數據包轉發到IP地址為192.168.1.1的路由器。
Destination Gateway Genmask Flags Metric Ref Use Iface ----------- ------- ------- ----- ----- --- --- ----- 192.19.12 192.168.1.1 255.255.255.0 UN 0 0 0 eth0
- 默認路由：當主機不能在路由表中查找到目標主機的IP地址或網絡路由時，數據包就被發送到默認路由（默認網關）上。默認路由的Flags字段為G。
Destination Gateway Genmask Flags Metric Ref Use Iface ----------- ------- ------- ----- ------ --- --- ----- default 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
設置和查看路由表都可以用 route 命令，設置內核路由表的命令格式是：route [add|del] [-net|-host] target [netmask Nm] [gw Gw] [[dev] If]
其中：
- add : 添加一條路由規則，del : 刪除一條路由規則，-net : 目的地址是一個網絡，-host : 目的地址是一個主機，target : 目的網絡或主機
- netmask : 目的地址的網絡掩碼，gw : 路由數據包通過的網關，dev : 為路由指定的網絡接口
比如：
- route add 0.0.0.0 mask 0.0.0.0 192.168.12.1
- route add 10.41.0.0 mask 255.255.0.0 10.27.0.1 metric 7
關於 src 屬性：
當一個主機有多個網卡配置了多個 IP 的時候，對於它產生的網絡包，可以在路由選擇時設置源 IP 地址。比如：
ip route add 78.22.45.0/24 via 10.45.22.1 src 10.45.22.12 （發到 78.22.45.0/24 網段的網絡包，下一跳的路由器 IP 是 10.45.22.1，包的源IP地址設為10.45.22.12）。
要注意的是，src 選項只會影響該 host 上產生的網絡包。如果是一個被路由的外來包，明顯地它已經帶有了一個源 IP 地址，這時候，src 參數的配置對它沒有任何影響，除非你使用 NAT 來改變它。對 Neutron 來說，qrouter 和 qif namespace 中的路由表中的 src 都沒有實際意義，因為它們只會處理外來的網絡包。
1.1.3 路由分類之靜態路由
靜態路由是指由用戶或網絡管理員手工配置的路由信息。當網絡的拓撲結構或鏈路的狀態發生變化時，網絡管理員需要手工去修改路由表中相關的靜態路由信息。靜態路由信息在缺省情況下是私有的，不會傳遞給其他的路由器。當然，網管員也可以通過對路由器進行設置使之成為共享的。靜態路由一般適用於比較簡單的網絡環境，在這樣的環境中，網絡管理員易於清楚地了解網絡的拓撲結構，便於設置正確的路由信息。
以上面的拓撲結構為例，在沒有配置路由的情況下，計算機1 和 2 無法互相通信，因為 1 發給 2 的包在到達路由器 A 后，它不知道怎么轉發它。B 也同樣。管理員可以配置如下的靜態路由來實現 1 和 2 之間的通信：
計算機配置默認網關：
- 計算機1 上：route add default gw 192.168.1.1
- 計算機2 上：route add default gw 192.168.3.1
路由器配置：
- R1 上：ip route 192.168.3.0 255.255.255.0 f0/1 （意思為：目標網絡地址為 192.168.3.0/24 的數據包，經過 f0/1 端口發出）
- R2 上：ip route 192.168.1.0 255.255.255.0 f0/1 （意思為：目標網絡地址為 192.168.1.0/24 的數據包，經過 f0/1 端口發出）
或者
- R1 上：ip route 192.168.3.0 255.255.255.0 192.168.2.2 （意思為：要去 192.168.3.0/24 的數據包，下一路由器 IP 地址為 192.168.2.2）
- R2 上：ip route 192.168.1.0 255.255.255.0 192.168.2.1
（來源：http://baike.baidu.com/view/911.htm）
1.1.4 路由分類之動態路由
動態路由是指路由器能夠自動地建立自己的路由表，並且能夠根據實際情況的變化適時地進行調整。它是與靜態路由相對的一個概念，指路由器能夠根據路由器之間的交換的特定路由信息自動地建立自己的路由表，並且能夠根據鏈路和節點的變化適時地進行自動調整。當網絡中節點或節點間的鏈路發生故障，或存在其它可用路由時，動態路由可以自行選擇最佳的可用路由並繼續轉發報文。
常見的動態路由協議有以下幾個：路由信息協議（RIP）、OSPF(Open Shortest Path First開放式最短路徑優先）、IS-IS（Intermediate System-to-Intermediate System，中間系統到中間系統）、邊界網關協議（BGP）是運行於 TCP 上的一種自治系統的路由協議。
（來源：http://baike.baidu.com/view/897.htm）
1.1.5 ip rule，ip route，iptables 三者之間的關系
以一例子來說明：公司內網要求192.168.0.100 以內的使用 10.0.0.1 網關上網 （電信），其他IP使用 20.0.0.1 （網通）上網。
- 首先要在網關服務器上添加一個默認路由，當然這個指向是絕大多數的IP的出口網關：ip route add default gw 20.0.0.1
- 之后通過 ip route 添加一個路由表：ip route add table 3 via 10.0.0.1 dev ethX (ethx 是 10.0.0.1 所在的網卡, 3 是路由表的編號)
- 之后添加 ip rule 規則：ip rule add fwmark 3 table 3 （fwmark 3 是標記，table 3 是路由表3 上邊。 意思就是凡事標記了 3 的數據使用 table3 路由表）
- 之后使用 iptables 給相應的數據打上標記：iptables -A PREROUTING -t mangle -i eth0 -s 192.168.0.1 - 192.168.0.100 -j MARK --set-mark 3
因為 mangle 的處理是優先於 nat 和 fiter 表的，所以在數據包到達之后先打上標記，之后再通過 ip rule 規則，對應的數據包使用相應的路由表進行路由，最后讀取路由表信息，將數據包送出網關。
（來源：使用 ip route ， ip rule ， iptables 配置策略路由。這里 有一個更詳細的例子）
這里可以看出 Netfilter 處理網絡包的先后順序：接收網絡包，先 DNAT，然后查路由策略，查路由策略指定的路由表做路由，然后 SNAT，再發出網絡包。
1.1.6 Traceroute 工具
我們在 linux 機器上，使用 traceroute 來獲知從你的計算機到互聯網另一端的主機是走的什么路徑。當然每次數據包由某一同樣的出發點（source）到達某一同樣的目的地(destination)走的路徑可能會不一樣，但基本上來說大部分時候所走的路由是相同的。在 MS Windows 中該工具為 tracert。 在大多數情況下，我們會在linux主機系統下，直接執行命令行：traceroute hostname；而在Windows系統下是執行tracert的命令： tracert hostname。
- 命令格式：traceroute [參數] [主機]
- 命令功能：traceroute 指令讓你追蹤網絡數據包的路由途徑，預設數據包大小是 40Bytes，用戶可另行設置。
- 具體參數格式：traceroute [-dFlnrvx][-f<存活數值>][-g<網關>...][-i<網絡界面>][-m<存活數值>][-p<通信端口>][-s<來源地址>][-t<服務類型>][-w<超時秒數>][主機名稱或IP地址][數據包大小]
- 命令參數：
- -d 使用Socket層級的排錯功能，-f 設置第一個檢測數據包的存活數值TTL的大小，-F 設置勿離斷位，-g 設置來源路由網關，最多可設置8個，-i 使用指定的網絡界面送出數據包，-I 使用ICMP回應取代UDP資料信息，-m 設置檢測數據包的最大存活數值TTL的大小，-n 直接使用IP地址而非主機名稱。
- -p 設置UDP傳輸協議的通信端口，-r 忽略普通的Routing Table，直接將數據包送到遠端主機上，-s 設置本地主機送出數據包的IP地址，-t 設置檢測數據包的TOS數值。
- -v 詳細顯示指令的執行過程，-w 設置等待遠端主機回報的時間，-x 開啟或關閉數據包的正確性檢驗。
（1）例子
[root@localhost ~]# traceroute www.baidu.com traceroute to www.baidu.com (61.135.169.125), 30 hops max, 40 byte packets 1 192.168.74.2 (192.168.74.2) 2.606 ms 2.771 ms 2.950 ms 2 211.151.56.57 (211.151.56.57) 0.596 ms 0.598 ms 0.591 ms 3 211.151.227.206 (211.151.227.206) 0.546 ms 0.544 ms 0.538 ms 4 210.77.139.145 (210.77.139.145) 0.710 ms 0.748 ms 0.801 ms 5 202.106.42.101 (202.106.42.101) 6.759 ms 6.945 ms 7.107 ms 6 61.148.154.97 (61.148.154.97) 718.908 ms * bt-228-025.bta.net.cn (202.106.228.25) 5.177 ms 7 124.65.58.213 (124.65.58.213) 4.343 ms 4.336 ms 4.367 ms 8 202.106.35.190 (202.106.35.190) 1.795 ms 61.148.156.138 (61.148.156.138) 1.899 ms 1.951 ms 9 * * * 30 * * *
說明：
- 記錄按序列號從1開始，每個紀錄就是一跳 ，每跳表示一個網關，我們看到每行有三個時間，單位是 ms，其實就是 -q 的默認參數。
- 探測數據包向每個網關發送三個數據包后，網關響應后返回的時間；如果您用 traceroute -q 4 www.58.com ，表示向每個網關發送4個數據包。
- 有時我們 traceroute 一台主機時，會看到有一些行是以星號表示的。出現這樣的情況，可能是防火牆封掉了ICMP 的返回信息，所以我們得不到什么相關的數據包返回數據。
- 有時我們在某一網關處延時比較長，有可能是某台網關比較阻塞，也可能是物理設備本身的原因。當然如果某台 DNS 出現問題時，不能解析主機名、域名時，也會 有延時長的現象；您可以加-n 參數來避免DNS解析，以IP格式輸出數據。
- 如果在局域網中的不同網段之間，我們可以通過 traceroute 來排查問題所在，是主機的問題還是網關的問題。如果我們通過遠程來訪問某台服務器遇到問題時，我們用到traceroute 追蹤數據包所經過的網關，提交IDC服務商，也有助於解決問題；但目前看來在國內解決這樣的問題是比較困難的，就是我們發現問題所在，IDC服務商也不可能幫助我們解決。
（2）原理
Traceroute 程序的設計是利用 ICMP 及 IP header 的 TTL（Time To Live）欄位（field）。
- 首先，traceroute 送出一個 TTL 是 1 的 IP datagram（其實，每次送出的為3個40字節的包，包括源地址，目的地址和包發出的時間標簽）到目的地，當路徑上的第一個路由器（router）收到這個datagram 時，它將TTL減1。此時，TTL變為0了，所以該路由器會將此 datagram 丟掉，並送回一個「ICMP time exceeded」消息（包括發IP包的源地址，IP包的所有內容及路由器的IP地址），traceroute 收到這個消息后，便知道這個路由器存在於這個路徑上。
- 接着，traceroute 再送出另一個TTL 是 2 的datagram，發現第2 個路由器......
- 然后，traceroute 每次將送出的 datagram 的 TTL 加1來發現另一個路由器，這個重復的動作一直持續到某個datagram 抵達目的地。當datagram到達目的地后，該主機並不會送回ICMP time exceeded消息，因為它已是目的地了，那么traceroute如何得知目的地到達了呢？
Traceroute 在送出 UDP datagrams 到目的地時，它所選擇送達的 port number 是一個一般應用程序都不會用的號碼（30000 以上），所以當此 UDP datagram 到達目的地后該主機會送回一個「ICMP port unreachable」的消息，而當traceroute 收到這個消息時，便知道目的地已經到達了。所以traceroute 在Server端也是沒有所謂的Daemon 程式。Traceroute提取發 ICMP TTL 到期消息設備的 IP 地址並作域名解析。每次 ，Traceroute 都打印出一系列數據,包括所經過的路由設備的域名及 IP地址,三個包每次來回所花時間。
（以上資料來自互聯網）
2. Neutron 的傳統和 DVR Router
2.1 傳統（Legacy） Router
關於這種 Router，可以參考我的另一篇文章 Neutron 理解 (6): Neutron 是怎么實現虛擬三層網絡的 [How Neutron implements virtual L3 network]。
2.2 DVR 對 L3 Agent 的影響
通過使用 DVR，三層的轉發（L3 Forwarding）和 NAT 功能都會被分布到計算節點上，這意味着計算節點也有了網絡節點的功能。但是，DVR 依然不能消除集中式的 Virtual Router，這是為了節省寶貴的 IPV4 公網地址，所有依然將 SNAT 放在網絡節點上提供。這樣，計算和網絡節點就看起來如下：
- 網絡節點：提供 南-北 SNAT，即在不使用浮動 IP 時，虛機訪問外網的網絡得經過網絡節點。也就是說，網絡節點依然必須走傳統的 HA 解決方法，比如 VRRP 和 PeaceMaker。但可惜的是，Juno 版本不支持同時使用 HA 和 DVR。
- 計算節點：提供 南-北 DNAT， 即外網訪問虛機的網絡流量得經過計算節點；以及 東-西 轉發，即虛機之間的網絡經過計算節點。因為所有計算節點的參與，這部分的網絡處理負載也就自然地被均衡了。
2.3 DVR 對 L2 Agent 的影響
DVR 對 L2 Agent 的影響主要有：
- DVR 新創建安的各個 network namespace 需要被 plug 到 OVS bridge
- OVS flows 需要更新來支持 DVR
詳細的分析在 https://wiki.openstack.org/wiki/Neutron/DVR_L2_Agent 以及本文下文。
3. 安裝和功能分析
3.1 安裝和配置
Juno 版本中 DVR 的要求如下：
- 使用 ML2 plugin
- 使用 L2pop mechanism driver
- 使用 Openvswitch mechanism driver, 安裝 OVS agent 在所有的計算節點上
- 所有的計算節點連接外網
- Juno 中只支持 Tunnel 虛擬網絡模式 (VXLAN or GRE)。 Kilo 版本中會增加 VLAN 模式的支持。
3.1.1 安裝
使用兩個結算節點。在每個計算節點上安裝並配置 L3 Agent：
（1）修改系統配置
root@compute2:/var/log/nova# vi /etc/sysctl.conf root@compute2:/var/log/nova# sysctl -p net.ipv4.ip_forward = 1 net.ipv4.conf.all.rp_filter = 0 net.ipv4.conf.default.rp_filter = 0
（2）安裝 neutron-l3-agent： apt-get install neutron-l3-agent
（3）增加一塊訪問外網的網卡 eth3
（4）創建 OVS bridge：ovs-vsctl add-br br-ex
（5）增加新的網卡到該 bridge 上：ovs-vsctl add-port br-ex eth3
（6）配置 L3 Agent
interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver use_namespaces = True external_network_bridge = br-eth3
（7）配置 Metadata Agent
3.1.2 配置 DVR
| 控制節點 | /etc/neutron/neutron.conf | router_distributed = True | 注意：需要設置 l3_ha = false 來禁用 VRRP |
| 計算節點 | /etc/neutron/l3_agent.ini /etc/neutron/plugins/ml2/ml2_conf.ini |
agent_mode = dvr enable_distributed_routing = True |
|
| 網絡節點 | /etc/neutron/l3_agent.ini /etc/neutron/plugins/ml2/ml2_conf.ini |
agent_mode = dvr_snat enable_distributed_routing = True |
注意還需要配置使用 l2_population。
對普通用戶來說，neutron 會根據管理員在控制節點上的配置項 router_distributed 的值，來決定是創建普通 Router 還是 DVR Router；對管理員來說，還可以使用 --distributed {True,False} 參數來指定是否創建 DVR 模式的 router。
經過以上配置后的 neutron agent如下。可以看到，除了網絡節點外，所有的計算介紹上也部署了 L3 Agent 和 Metadata Agent。
s1@controller:~$ neutron agent-list +--------------------------------------+--------------------+----------+-------+----------------+---------------------------+ | id | agent_type | host | alive | admin_state_up | binary | +--------------------------------------+--------------------+----------+-------+----------------+---------------------------+ | 04c360d0-3066-4f04-9af2-d4ef8586ad2b | L3 agent | network | :-) | True | neutron-l3-agent | | 2ef04905-4a37-4de8-a8f0-9c6488a592b7 | Open vSwitch agent | network | :-) | True | neutron-openvswitch-agent | | 3f307355-2167-4b15-affa-9f296f698752 | DHCP agent | network | :-) | True | neutron-dhcp-agent | | 54609006-a769-4b17-b175-1a834e6e7a26 | Open vSwitch agent | compute1 | :-) | True | neutron-openvswitch-agent | | 90c87c01-1cd1-48b0-8369-30f44c058574 | Loadbalancer agent | network | :-) | True | neutron-lbaas-agent | | 951b8efc-1f2c-4a51-84d1-2261ff31c12c | Metadata agent | compute2 | :-) | True | neutron-metadata-agent | | 99d13b27-89f8-4abe-bc03-3f69f5e7e0cc | Metadata agent | network | :-) | True | neutron-metadata-agent | | aa8cf021-7f3d-4667-9d92-4d77d4c4fb59 | L3 agent | compute2 | :-) | True | neutron-l3-agent | | beec232b-48d7-4424-83e2-8cc4e49ec339 | L3 agent | compute1 | :-) | True | neutron-l3-agent | | d65bbede-4b1d-4914-8c8b-ab591975828f | Metadata agent | compute1 | :-) | True | neutron-metadata-agent | | e3f83dcf-27f2-4c91-bead-adebcab1e3c7 | Open vSwitch agent | compute2 | :-) | True | neutron-openvswitch-agent | +--------------------------------------+--------------------+----------+-------+----------------+---------------------------+
3.2 DVR Router 流程
3.2.1 創建 DVR Router
（1）創建如下的 DVR Router：
可以看到該 router 被分布在neutron network 節點和計算節點上：
s1@controller:~$ neutron l3-agent-list-hosting-router dvr-r1 +--------------------------------------+----------+----------------+-------+ | id | host | admin_state_up | alive | +--------------------------------------+----------+----------------+-------+ | 04c360d0-3066-4f04-9af2-d4ef8586ad2b | network | True | :-) | | beec232b-48d7-4424-83e2-8cc4e49ec339 | compute1 | True | :-) | +--------------------------------------+----------+----------------+-------+
（2）網絡節點上，創建了 SNAT network namespace。該 netns 中，對router 的每一個網絡，都有一個 qg 或者 sg interface：
root@network:/home/s1# ip netns exec snat-e8f12f7a-6938-4e65-88c4-97e4cb211b27 ip addr 42: qg-32878e35-a2: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default #對應 port 1，連接外網 link/ether fa:16:3e:4a:40:48 brd ff:ff:ff:ff:ff:ff inet 192.168.1.115/24 brd 192.168.1.255 scope global qg-32878e35-a2 valid_lft forever preferred_lft forever 44: sg-4f80ec3d-f2: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default #對應 port 2，連接內網1 link/ether fa:16:3e:82:a9:ca brd ff:ff:ff:ff:ff:ff inet 81.1.180.17/24 brd 81.1.180.255 scope global sg-4f80ec3d-f2 valid_lft forever preferred_lft forever 46: sg-6c01abc3-5d: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default #對應 port 4，連接內網2 link/ether fa:16:3e:47:55:00 brd ff:ff:ff:ff:ff:ff inet 91.1.180.16/24 brd 91.1.180.255 scope global sg-6c01abc3-5d valid_lft forever preferred_lft forever root@network:/home/s1# ip netns exec snat-e8f12f7a-6938-4e65-88c4-97e4cb211b27 iptables -t nat -S -A POSTROUTING -j neutron-l3-agent-POSTROUTING -A POSTROUTING -j neutron-postrouting-bottom -A neutron-l3-agent-POSTROUTING ! -i qg-32878e35-a2 ! -o qg-32878e35-a2 -m conntrack ! --ctstate DNAT -j ACCEPT -A neutron-l3-agent-snat -s 81.1.180.0/24 -j SNAT --to-source 192.168.1.115 -A neutron-l3-agent-snat -s 91.1.180.0/24 -j SNAT --to-source 192.168.1.115 -A neutron-postrouting-bottom -j neutron-l3-agent-snat
以及 qrouter network namespace：
root@network:/home/s1# ip netns exec qrouter-e8f12f7a-6938-4e65-88c4-97e4cb211b27 ip addr
43: qr-517bdba3-b1: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default #對應 port 3
link/ether fa:16:3e:63:3b:4c brd ff:ff:ff:ff:ff:ff
inet 81.1.180.1/24 brd 81.1.180.255 scope global qr-517bdba3-b1
valid_lft forever preferred_lft forever
45: qr-e47fca31-db: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default #對應 port 5
link/ether fa:16:3e:a9:da:b5 brd ff:ff:ff:ff:ff:ff
inet 91.1.180.1/24 brd 91.1.180.255 scope global qr-e47fca31-db
valid_lft forever preferred_lft forever
root@network:/home/s1# ip netns exec qrouter-e8f12f7a-6938-4e65-88c4-97e4cb211b27 iptables -t nat -S
-A neutron-l3-agent-PREROUTING -d 169.254.169.254/32 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 9697
-A neutron-l3-agent-snat -j neutron-l3-agent-float-snat
-A neutron-postrouting-bottom -j neutron-l3-agent-snat
（3）在計算節點 compute1 上創建一個虛機
在 compute1 上生成了一個 qrouter network namespace：
root@compute1:/home/s1# ip netns exec qrouter-e8f12f7a-6938-4e65-88c4-97e4cb211b27 ip addr 29: qr-517bdba3-b1: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default #對應 port 3，作為 81.1.180.1/24 網段內的虛機的默認網關 link/ether fa:16:3e:63:3b:4c brd ff:ff:ff:ff:ff:ff inet 81.1.180.1/24 brd 81.1.180.255 scope global qr-517bdba3-b1 valid_lft forever preferred_lft forever inet6 fe80::f816:3eff:fe63:3b4c/64 scope link valid_lft forever preferred_lft forever 31: qr-e47fca31-db: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default #對應 port 5，作為 91.1.180.1/24 網段內的虛機的默認網關 link/ether fa:16:3e:a9:da:b5 brd ff:ff:ff:ff:ff:ff inet 91.1.180.1/24 brd 91.1.180.255 scope global qr-e47fca31-db valid_lft forever preferred_lft forever inet6 fe80::f816:3eff:fea9:dab5/64 scope link valid_lft forever preferred_lft forever
root@compute1:/home/s1# ip netns exec qrouter-e8f12f7a-6938-4e65-88c4-97e4cb211b27 iptables -t nat -S
-A neutron-l3-agent-PREROUTING -d 169.254.169.254/32 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 9697
（4）給虛機分配一個浮動IP 后，compute1 上出現了 fip network namespace。該 netns 的命名規則是 fip-<external net id>，這里的 external net 是指該浮動IP所在的外網的：
root@compute1:/home/s1# ip netns exec fip-557e9f0c-9c66-46da-b289-218d49c218d2 ip addr
2: fpr-e8f12f7a-6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 #該 port 和 qrouter 中的 rpf port 是一對 veth pair，各自配置了自己的 IP 地址
link/ether 9a:d0:23:ba:d2:02 brd ff:ff:ff:ff:ff:ff
inet 169.254.31.29/31 scope global fpr-e8f12f7a-6
valid_lft forever preferred_lft forever
inet6 fe80::98d0:23ff:feba:d202/64 scope link
valid_lft forever preferred_lft forever
32: fg-9eeb3fb1-25: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
link/ether fa:16:3e:22:2d:90 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.117/24 brd 192.168.1.255 scope global fg-9eeb3fb1-25
valid_lft forever preferred_lft forever
inet6 fe80::f816:3eff:fe22:2d90/64 scope link
valid_lft forever preferred_lft forever
root@compute1:/home/s1# ip netns exec fip-557e9f0c-9c66-46da-b289-218d49c218d2 ip route
default via 192.168.1.1 dev fg-9eeb3fb1-25
169.254.31.28/31 dev fpr-e8f12f7a-6 proto kernel scope link src 169.254.31.29
192.168.1.0/24 dev fg-9eeb3fb1-25 proto kernel scope link src 192.168.1.117
192.168.1.116 via 169.254.31.28 dev fpr-e8f12f7a-6
而且，compute1 上的 qrouter netns 中的變化：
root@compute1:/home/s1# ip netns exec qrouter-e8f12f7a-6938-4e65-88c4-97e4cb211b27 ip addr 2: rfp-e8f12f7a-6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 #該 port 和 fip 中的 pfr port 是一對 veth，各自配置了自己的 IP 地址，該地址來自 169.254.x.y 網段 link/ether 42:81:66:11:60:66 brd ff:ff:ff:ff:ff:ff inet 169.254.31.28/31 scope global rfp-e8f12f7a-6 valid_lft forever preferred_lft forever inet 192.168.1.116/32 brd 192.168.1.116 scope global rfp-e8f12f7a-6 valid_lft forever preferred_lft forever
NAP iptables 規則：
-A neutron-l3-agent-OUTPUT -d 192.168.1.116/32 -j DNAT --to-destination 81.1.180.18
-A neutron-l3-agent-POSTROUTING ! -i rfp-e8f12f7a-6 ! -o rfp-e8f12f7a-6 -m conntrack ! --ctstate DNAT -j ACCEPT
-A neutron-l3-agent-PREROUTING -d 169.254.169.254/32 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 9697
-A neutron-l3-agent-PREROUTING -d 192.168.1.116/32 -j DNAT --to-destination 81.1.180.18
-A neutron-l3-agent-float-snat -s 81.1.180.18/32 -j SNAT --to-source 192.168.1.116
以及一條路由策略。具體見下文。
但是 neutron 網絡節點上的 qrouter 上並沒有增加該浮動 IP和相應的 NAT iptables 規則。
3.2 網絡包走向分析
不同網段內的虛機之間或者虛機和計算機之間的網絡流向可以分為幾類：
- 3.2.1 SNAT：當數據包離開 rouer 的 external device 時改變它的源 IP 地址。這在沒有浮動IP 時虛機訪問外網的情況下使用。
- 3.2.2/3 FIP：有時候也稱為 DNAT。當虛機的固定 IP分配了浮動 IP 的時候，虛機和外網中的虛機通信的時候使用。
- 3.2.4 不同服務器上不同網段內的虛機之間的通信
- 3.2.5 同一個服務器上不同網段內的虛機之間的通信
3.2.1 SNAT：虛機訪問外網（沒有分配浮動IP 的情況下）
Neuron 布網：
虛機（81.1.180.18）發出給外網中機器（192.168.1.20）的包，因為是跨網段的，先發給 compute1 上的 qrouter 的 qr-517bdba3-b1 interface。然后，qruoter 查路由表：
root@compute1:/home/s1# ip netns exec qrouter-e8f12f7a-6938-4e65-88c4-97e4cb211b27 ip rule 0: from all lookup local 32766: from all lookup main 32767: from all lookup default 1359066113: from 81.1.180.1/24 lookup 1359066113 1526838273: from 91.1.180.1/24 lookup 1526838273
root@compute1:/home/s1# ip netns exec qrouter-e8f12f7a-6938-4e65-88c4-97e4cb211b27 ip route list table 1359066113 #只有一個默認路由
default via 81.1.180.17 dev qr-517bdba3-b1 #經過 qr 端口發到下一個路由器 81.1.180.17
查表結果是經過 interface qr-517bdba3-b1 將包發到下一個路由器 81.1.180.17，而這個IP 在 neutron 網絡節點上的 SNAT netns 的 44: sg-4f80ec3d-f2 interface。在這里，先做 SNAT：
root@network:/home/s1# ip netns exec snat-e8f12f7a-6938-4e65-88c4-97e4cb211b27 iptables -t nat -S
-A neutron-l3-agent-POSTROUTING ! -i qg-32878e35-a2 ! -o qg-32878e35-a2 -m conntrack ! --ctstate DNAT -j ACCEPT -A neutron-l3-agent-snat -s 81.1.180.0/24 -j SNAT --to-source 192.168.1.115 # 命中這條，把網絡包的 Src IP 修改為 192.168.1.115 -A neutron-l3-agent-snat -s 91.1.180.0/24 -j SNAT --to-source 192.168.1.115 -A neutron-postrouting-bottom -j neutron-l3-agent-snat
然后查路由表確定下一跳：
root@network:/home/s1# ip netns exec snat-e8f12f7a-6938-4e65-88c4-97e4cb211b27 ip rule show #這里沒定義額外的路由策略，直接查 main 路由表
0: from all lookup local
32766: from all lookup main
32767: from all lookup default
root@network:/home/s1# ip netns exec snat-e8f12f7a-6938-4e65-88c4-97e4cb211b27 ip route list table main
default via 192.168.1.1 dev qg-32878e35-a2
81.1.180.0/24 dev sg-4f80ec3d-f2 proto kernel scope link src 81.1.180.17
91.1.180.0/24 dev sg-6c01abc3-5d proto kernel scope link src 91.1.180.16
192.168.1.0/24 dev qg-32878e35-a2 proto kernel scope link src 192.168.1.115 #根據目的地址，命中這條，網絡包從 qg 端口發出
結論：在沒有設置浮動 IP （SNAT）的情況下，虛機訪問外網時，虛機發出的網絡包首先經過其所在的服務器上的 qrouter 做路由選擇（81.1.180.1），然后再經過 neutron network 節點上的 snat network namespace （81.1.180.17）出去到外網。這個結論也和 traceroute 的結果互相驗證：
完整過程：
3.2.2 FIP：在虛機 81.1.180.18 上添加浮動IP，從它 ping 外網
Neutron 組網：
添加浮動 IP 后，虛機所在的主機上的 qrouter netns 上添加了浮動IP：
root@compute1:/home/s1# ip netns exec qrouter-e8f12f7a-6938-4e65-88c4-97e4cb211b27 ip addr 3: rfp-e8f12f7a-6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 46:ef:97:f4:4d:ff brd ff:ff:ff:ff:ff:ff inet 169.254.31.238/31 scope global rfp-e8f12f7a-6 valid_lft forever preferred_lft forever inet 192.168.1.112/32 brd 192.168.1.112 scope global rfp-e8f12f7a-6 valid_lft forever preferred_lft forever
還增加了一條路由策略及路由表：
root@compute1:/home/s1# ip netns exec qrouter-e8f12f7a-6938-4e65-88c4-97e4cb211b27 ip rule
0: from all lookup local
32766: from all lookup main
32767: from all lookup default
32769: from 81.1.180.18 lookup 16 #每個固定 IP 對應一條路由策略，都查 ID 為 16 的路由表
root@compute1:/home/s1# ip netns exec qrouter-e8f12f7a-6938-4e65-88c4-97e4cb211b27 ip route list table 16
default via 169.254.31.239 dev rfp-e8f12f7a-6
（1）網絡包從虛機觸發，進入本服務器所在的 qrouter 的 qr interface，首先經過 DNAT，沒有命中，然后查路由表，local，main，default 中沒有命中的路由規則，查表 16，命中默認路由，需要經過 rfp 端口發到下一個路由器 169.254.31.239。
（2）rfp 端口是這樣子：
3: rfp-e8f12f7a-6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 46:ef:97:f4:4d:ff brd ff:ff:ff:ff:ff:ff inet 169.254.31.238/31 scope global rfp-e8f12f7a-6 valid_lft forever preferred_lft forever inet 192.168.1.112/32 brd 192.168.1.112 scope global rfp-e8f12f7a-6 valid_lft forever preferred_lft forever
（3）該 rfp 和 fip netns 上的端口通過 veth 直接連接：
root@compute1:/home/s1# ip netns exec fip-557e9f0c-9c66-46da-b289-218d49c218d2 ip addr2:
fpr-e8f12f7a-6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 9a:4d:66:1c:b5:2b brd ff:ff:ff:ff:ff:ff inet 169.254.31.239/31 scope global fpr-e8f12f7a-6 valid_lft forever preferred_lft forever
（4）看 fip netns 的路由表，決定將其從 fg interface 發出去。
root@compute1:/home/s1# ip netns exec fip-557e9f0c-9c66-46da-b289-218d49c218d2 ip route
default via 192.168.1.1 dev fg-4a292fe1-58
169.254.31.238/31 dev fpr-e8f12f7a-6 proto kernel scope link src 169.254.31.239
192.168.1.0/24 dev fg-4a292fe1-58 proto kernel scope link src 192.168.1.118
192.168.1.112 via 169.254.31.238 dev fpr-e8f12f7a-6
（5）再經過 SNAT，經 Src 地址換成浮動 IP 地址：-A neutron-l3-agent-float-snat -s 81.1.180.18/32 -j SNAT --to-source 192.168.1.112
結論：配有浮動IP的虛機上 ping 外網，依次經過虛機所在的服務器上的 qrouter （81.1.180.1）和 fip netns （169.254.31.239） 到外網機器（192.168.1.20）。
完整路徑：
3.2.3 FIP：外網機器通過虛機的浮動 IP 訪問虛機
外網中的機器首先要通過 ARP 獲取虛機浮動 IP 對應的 MAC 地址。浮動 IP 並沒有配置在 fip 的端口上，因此 fip 無法直接響應 ARP 請求，那怎么辦呢？Neutron 在 fip NS 的 fg 端口上配置了 arp proxy，這樣，fip 既可以響應它自己的 interface 上的 IP 地址的 ARP 請求，也可以響應能通過它路由到的 IP 地址的 ARP 請求。
（1）從下圖可見，fip netns 的 fg-4a292fe1-58 interface 上配置了 ARP 代理：
root@compute1:/home/s1# ip netns exec fip-557e9f0c-9c66-46da-b289-218d49c218d2 sysctl net.ipv4.conf.fg-4a292fe1-58.proxy_arp net.ipv4.conf.fg-4a292fe1-58.proxy_arp = 1
而 qrouter 的 interface 沒有設置 arp proxy： root@compute1:/home/s1# ip netns exec qrouter-e8f12f7a-6938-4e65-88c4-97e4cb211b27 sysctl net.ipv4.conf.rfp-e8f12f7a-6.proxy_arp net.ipv4.conf.rfp-e8f12f7a-6.proxy_arp = 0
（2）fip netns 收到 ARP 請求后，將其 fg interface 的 MAC 地址返回。其實這是一個 MAC 地址欺騙，但是。。這就是一個 arp proxy 所起的作用。
外網中的機器獲取到虛機浮動 IP 的 MAC 地址后，發出 ICMP 網絡包（Dest IP: 192.168.1.112，Souce IP: 192.168.1.20，Dest MAC: fa:16:3e:95:55:29
（fip 的 fg interface 的 MAC 地址），Source MAC: MAC of 192.168.1.20）：
（1）網絡包經過 br-ex，被 fip 的 fg 端口收到，查路由表，命中最后一條路由，從其 fpr interface 發出，到達 169.254.31.238.
root@compute1:/home/s1# ip netns exec fip-557e9f0c-9c66-46da-b289-218d49c218d2 ip route
default via 192.168.1.1 dev fg-4a292fe1-58
169.254.31.238/31 dev fpr-e8f12f7a-6 proto kernel scope link src 169.254.31.239
192.168.1.0/24 dev fg-4a292fe1-58 proto kernel scope link src 192.168.1.118
192.168.1.112 via 169.254.31.238 dev fpr-e8f12f7a-6
17:38:41.462365 9a:4d:66:1c:b5:2b > 46:ef:97:f4:4d:ff, ethertype IPv4 (0x0800), length 98: (tos 0x0, flags [DF], proto ICMP (1), length 84) 192.168.1.20 > 192.168.1.112: ICMP echo request, id 3138, seq 180, length 64
（2）被 veth 另一端的 qrouter 的 rfp-e8f12f7a-6 interface 收到。
3: rfp-e8f12f7a-6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 46:ef:97:f4:4d:ff brd ff:ff:ff:ff:ff:ff
inet 169.254.31.238/31 scope global rfp-e8f12f7a-6
valid_lft forever preferred_lft forever
inet 192.168.1.112/32 brd 192.168.1.112 scope global rfp-e8f12f7a-6
valid_lft forever preferred_lft forever
（3）在 qrouter 上，首先做 DNAT：
-A neutron-l3-agent-PREROUTING -d 192.168.1.112/32 -j DNAT --to-destination 81.1.180.18。將目的 IP 由浮動 IP 修改為固定 IP。
（4）查 qrouter 的 main 路由表，命中第一條，從 qr-517bdba3-b1 發出
root@compute1:/home/s1# ip netns exec qrouter-e8f12f7a-6938-4e65-88c4-97e4cb211b27 ip route
81.1.180.0/24 dev qr-517bdba3-b1 proto kernel scope link src 81.1.180.1
91.1.180.0/24 dev qr-e47fca31-db proto kernel scope link src 91.1.180.1
169.254.31.238/31 dev rfp-e8f12f7a-6 proto kernel scope link src 169.254.31.238
17:43:21.363808 fa:16:3e:63:3b:4c > fa:16:3e:30:ee:23, ethertype IPv4 (0x0800), length 98: (tos 0x0, flags [DF], proto ICMP (1), length 84) 192.168.1.20 > 81.1.180.18: ICMP echo request, id 3202, seq 221, length 64
（5）SNAT：沒有
（6）網絡包經過 br-int，然后到達虛機
3.2.4 不同服務器上不同網段上的虛機互相訪問
在另一個計算節點上新建虛機，固定 IP 為 90.1.180.6。從虛機 81.1.180.18 上 ping 它，看看網絡包的走向。新建虛機后，compute 2 節點上也分布了 router 實例：
s1@controller:~$ neutron l3-agent-list-hosting-router dvr-r1
+--------------------------------------+----------+----------------+-------+
| id | host | admin_state_up | alive |
+--------------------------------------+----------+----------------+-------+
| 04c360d0-3066-4f04-9af2-d4ef8586ad2b | network | True | :-) |
| aa8cf021-7f3d-4667-9d92-4d77d4c4fb59 | compute2 | True | :-) |
| beec232b-48d7-4424-83e2-8cc4e49ec339 | compute1 | True | :-) |
+--------------------------------------+----------+----------------+-------+
在 compute 2 上，創建了 qrouter network namespace，其中的配置和 compute 1 上的 qrouter 的配置完全相同。
（1）網絡包離開 vm1，通過br-int，進入 compute 1 上的 qrouter 的 qr-517bdba3-b1，查 main 路由表，從 qr-e47fca31-db 出。
08:17:14.483282 fa:16:3e:30:ee:23 > fa:16:3e:63:3b:4c, ethertype IPv4 (0x0800), length 98: (tos 0x0, flags [DF], proto ICMP (1), length 84)
81.1.180.18 > 90.1.180.6: ICMP echo request, id 12033, seq 4, length 64
root@compute1:/home/s1# ip netns exec qrouter-e8f12f7a-6938-4e65-88c4-97e4cb211b27 ip route list table main
81.1.180.0/24 dev qr-517bdba3-b1 proto kernel scope link src 81.1.180.1
90.1.180.0/24 dev qr-f849ae46-48 proto kernel scope link src 90.1.180.1
91.1.180.0/24 dev qr-e47fca31-db proto kernel scope link src 91.1.180.1
169.254.31.238/31 dev rfp-e8f12f7a-6 proto kernel scope link src 169.254.31.238
08:18:30.555867 fa:16:3e:ec:f3:dd > fa:16:3e:13:93:0d, ethertype IPv4 (0x0800), length 98: (tos 0x0, flags [DF], proto ICMP (1), length 84)
81.1.180.18 > 90.1.180.6: ICMP echo request, id 12033, seq 80, length 64
（2）網絡包重新進入 br-int，被它的 flows 處理。
root@compute1:/home/s1# ovs-ofctl dump-flows br-inttable=0, n_packets=0, n_bytes=0, idle_age=6318, priority=2,in_port=5,dl_src=fa:16:3f:12:a3:38 actions=resubmit(,1) table=0, n_packets=336, n_bytes=32928, idle_age=1, priority=2,in_port=5,dl_src=fa:16:3f:db:6f:73 actions=resubmit(,1) table=0, n_packets=12877, n_bytes=1220950, idle_age=1, priority=1 actions=NORMAL table=1, n_packets=0, n_bytes=0, idle_age=6309, priority=2,ip,dl_vlan=2,nw_dst=81.1.180.0/24 actions=strip_vlan,mod_dl_src:fa:16:3e:63:3b:4c,output:4table=1, n_packets=336, n_bytes=32928, priority=4,dl_vlan=2,dl_dst=fa:16:3e:30:ee:23 actions=strip_vlan,mod_dl_src:fa:16:3e:63:3b:4c,output:4table=1, n_packets=0, n_bytes=0, idle_age=6319, priority=1 actions=drop table=23, n_packets=0, n_bytes=0, idle_age=6319, priority=0 actions=drop
（3）進入 br-tun，依次被其 flows 處理：
root@compute1:/home/s1# ovs-ofctl dump-flows br-tun
NXST_FLOW reply (xid=0x4):
table=0, n_packets=6423, n_bytes=593912, idle_age=0, priority=1,in_port=1 actions=resubmit(,1)
table=1, n_packets=5751, n_bytes=563598, idle_age=0, priority=1,dl_vlan=1,dl_src=fa:16:3e:ec:f3:dd actions=mod_dl_src:fa:16:3f:b2:34:82,resubmit(,2)
table=2, n_packets=5768, n_bytes=565152, idle_age=0, priority=0,dl_dst=00:00:00:00:00:00/01:00:00:00:00:00 actions=resubmit(,20)
table=20, n_packets=0, n_bytes=0, idle_age=6900, priority=0 actions=resubmit(,22)
table=20, n_packets=11, n_bytes=1022, idle_age=3650, priority=2,dl_vlan=2,dl_dst=fa:16:3e:82:a9:ca actions=strip_vlan,set_tunnel:0x6,output:3
table=20, n_packets=5, n_bytes=490, idle_age=6411, priority=2,dl_vlan=1,dl_dst=fa:16:3e:47:55:00 actions=strip_vlan,set_tunnel:0x4,output:3
table=20, n_packets=0, n_bytes=0, idle_age=5820, priority=2,dl_vlan=1,dl_dst=fa:16:3e:54:f8:b8 actions=strip_vlan,set_tunnel:0x4,output:3
table=20, n_packets=1108, n_bytes=108584, idle_age=0, priority=2,dl_vlan=1,dl_dst=fa:16:3e:13:93:0d actions=strip_vlan,set_tunnel:0x4,output:2
table=20, n_packets=0, n_bytes=0, idle_age=6889, priority=2,dl_vlan=2,dl_dst=fa:16:3e:a1:76:41 actions=strip_vlan,set_tunnel:0x6,output:2
table=20, n_packets=1, n_bytes=42, idle_age=6685, priority=2,dl_vlan=2,dl_dst=fa:16:3e:c0:8f:2c actions=strip_vlan,set_tunnel:0x6,output:3
table=20, n_packets=0, n_bytes=0, idle_age=6782, priority=2,dl_vlan=1,dl_dst=fa:16:3e:69:92:30 actions=strip_vlan,set_tunnel:0x4,output:3
從這里可以看出：
- table 1 將網絡包的 src mac 修改為了 compute node 1 的 DVR MAC 地址。
- table 20 通過 l2population 獲得了到虛機所在的租戶網絡內的所有存在的虛機的 MAC 地址和 Tunnel 端口號的映射關系。至此，網絡包被打上了 Tunnel ID 4，進入 GRE Port 2.
- 其 GRE 隧道的另一頭正是 compute 2.
（4）到了 compute 2 上，依次被 br-tun，br-int 處理，直到通過 tap 設備進入 vm 2。
小結：
3.2.5 同一個服務器上不同網段上的虛機互相訪問
這里只經過 3.2.4 中的 （1） 和 （2），網絡包經過 br-int 直接進入 vm2.
3.3 小結
| 網絡流量類型 | 特征 | 轉發機制 |
| 本地 | 源和目的 IP 在同一個 subnet 中，虛機在同一個計算節點上 | br-int 通過 MAC 地址學習直接轉發網絡包給目標虛機 |
| 遠程 | 源和目的 IP 在同一個 subnet 中，虛機不在同一個計算節點上 | 標准轉發，取決於網絡的段類型 |
| 東-西 | 源和目的 IP 不在同一個 subnet 中 | 由源虛機所在計算節點上的 qrouter 負責轉發 |
| SNAT | IP 不屬於本地 router 的任何 subnet 中，而且虛機沒有浮動IP | 由源虛機所在計算節點上的 qrouter 負責轉發到 neutron 網絡節點上 snat |
| FIP | IP 不屬於本地 router 的任何 subnet 中，而且虛機有浮動IP | 由源虛機所在計算節點上的 qrouter轉發到本地的 fip |
4. 代碼分析
DVR 代碼修改包括幾部分：
- DVR Router network namespace 的創建和刪除
- DVR Router 相關的 flows
- DVR Router 的 ARP 表
4.1 DVR Router 相關 network namespace 的創建和刪除
4.1.1 qrouter 在計算和網絡節點上的刪除和創建
對於每一個 DVR Router，在每個分布了和 router 連接的網段內的虛機的計算節點上，都會有一個 qrouter 實例。兩種情況下會將一個 DVR Router 部署到一個 L3 Agent 上：
- 當一個子網 subnet 被加入到一個 DVR Router 時，DVR Router 會被分布到所有包含在該子網內的虛機的計算節點上。
-
- 計算節點上的 L3 Agent 會收到一個通知，它會配置 router
- OVS Agent 會將 router 的端口 plug 到 OVS Bridge 上，並且配置 flows
- 當一個虛機被創建，而且虛機所在的計算節點上不存在該虛機所在 subnet 連接的 DVR Router 時。
- 當與 DVR Router 相關的最后一個虛機被刪除時，router namespace 會被從虛機所在的計算節點上刪除。
4.1.2 snat 在網絡節點上的創建和刪除
創建：當設置 router 的 external gateway 時
刪除：當刪除 router 的 external gateway 時
4.1.3 fip 在 計算節點上的創建和刪除
創建：當一個浮動 IP 被分配給一個虛機的時候，如果虛機所在的計算節點上 fip namespace 不存在，則創建它
刪除：（1）當計算節點上最后一個使用浮動 IP 的虛機被刪除后 （2）所有虛機的浮動 IP 被刪除后
4.2 DVR MAC 地址
前面提到過，分布到多個計算節點上的 qrouter 的interface 的 MAC 地址都相同。這在傳統的網絡中是不允許的，在 neutron 網絡中某些時候也會導致一些問題。Neutron的做法是會向每個計算節點分配一個唯一的 DVR Host MAC 地址。當使用了 DVR 的 OVS Agent 啟動的時候，它通過 RPC 去從 neutron server 上申請該 MAC 地址。該 MAC 地址會被保存在 DB 中，與該計算節點強綁定。比如：
MariaDB [neutron]> select * from dvr_host_macs; +----------+-------------------+ | host | mac_address | +----------+-------------------+ | network | fa:16:3f:12:a3:38 | | compute1 | fa:16:3f:b2:34:82 | | compute2 | fa:16:3f:db:6f:73 | +----------+-------------------+
當數據包離開 DVR Router 經過 br-tun 時，OVS flows 會將 DVR Router interface 的源 MAC 地址替換成該 MAC 地址。
root@compute1:/home/s1# ovs-ofctl dump-flows br-tun | grep mod_dl_src
cookie=0x0, duration=6989.394s, table=1, n_packets=6405, n_bytes=627690, idle_age=510, priority=1,dl_vlan=1,dl_src=fa:16:3e:ec:f3:dd actions=mod_dl_src:fa:16:3f:b2:34:82,resubmit(,2)
cookie=0x0, duration=8055.165s, table=1, n_packets=10, n_bytes=980, idle_age=4814, priority=1,dl_vlan=2,dl_src=fa:16:3e:63:3b:4c actions=mod_dl_src:fa:16:3f:b2:34:82,resubmit(,2)
cookie=0x0, duration=8059.947s, table=1, n_packets=635, n_bytes=26950, idle_age=4843, priority=1,dl_vlan=1,dl_src=fa:16:3e:a9:da:b5 actions=mod_dl_src:fa:16:3f:b2:34:82,resubmit(,2)
而 src mac 地址分別是 qrouter 上的作為默認各網段的默認網關的 mac 地址：
s1@controller:~$ neutron port-list | grep fa:16:3e:ec:f3:dd | f849ae46-4819-45f5-a805-5970d4e31951 | | fa:16:3e:ec:f3:dd | {"subnet_id": "f8841500-b392-4053-bda1-acf419f4a86e", "ip_address": "90.1.180.1"} s1@controller:~$ neutron port-list | grep fa:16:3e:63:3b:4c | 517bdba3-b117-43ce-851b-bb1d039879dc | | fa:16:3e:63:3b:4c | {"subnet_id": "4ec65731-35a5-4637-a59b-a9f2932099f1", "ip_address": "81.1.180.1"} s1@controller:~$ neutron port-list | grep fa:16:3e:a9:da:b5 | e47fca31-dbf6-47e5-9ccb-0950557a55e3 | | fa:16:3e:a9:da:b5 | {"subnet_id": "13888749-12b3-462e-9afe-c527bd0a297e", "ip_address": "91.1.180.1"}
因此，這里假設你不會將多個 DVR Router 連接到一個 subnet。當數據包達到該計算節點時，OVS flows 會將其源 MAC 地址替換成 VM gateway 的 MAC 地址。
DVR-MAC-ADDRESS 的更新是 neutron server 通過 RPC Notifier 做的。每當一個新的地址被分配后，它通知所有的 L3 Agent 節點做處理。
4.3 DVR OVS flows
使用 DVR Router 的計算節點上，br-int 和 br-tun 中的 flows 會有修改。具體請參見上文的 3.2.4 部分。
4.3.1 br-int flows 的主要修改
table 1： DVR_TO_SRC_MAC
table 0：LOCAL_SWITCHING
root@compute1:/home/s1# ovs-ofctl dump-flows br-int NXST_FLOW reply (xid=0x4):
#獲取所有的 DVR_MAC_ADDRESS，然后
# 從 patch-tun 進入的 src mac 為 network 節點的 DVR HOST MAC 的網絡幀（也就是從 network 節點來的幀），重新提交 table 1 處理 table=0, n_packets=0, n_bytes=0, idle_age=9734, priority=2,in_port=5,dl_src=fa:16:3f:12:a3:38 actions=resubmit(,1)
# 從 compute 2 節點來的網絡幀，提交到 table 1 table=0, n_packets=2321, n_bytes=227458, idle_age=0, priority=2,in_port=5,dl_src=fa:16:3f:db:6f:73 actions=resubmit(,1)
#本機上的虛機產生的網絡幀，走常規的轉發模式發到虛機或者 br-tun table=0, n_packets=22797, n_bytes=2176300, idle_age=0, priority=1 actions=NORMAL
#目標網段是 81.1.180.0/24 網段的幀，去掉 vlan tag，修改 src mac 為 qrouter 的 81.1.180.1 interface 的 mac 地址，發到虛機 table=1, n_packets=0, n_bytes=0, idle_age=9725, priority=2,ip,dl_vlan=2,nw_dst=81.1.180.0/24 actions=strip_vlan,mod_dl_src:fa:16:3e:63:3b:4c,output:4
#目標網段是 90.1.180.0/24 網段的幀，去掉 vlan tag，修改 src mac 為qrouter 的 90.1.180.1 interface 的 mac 地址，發到虛機 table=1, n_packets=0, n_bytes=0, idle_age=2268, priority=2,ip,dl_vlan=1,nw_dst=90.1.180.0/24 actions=strip_vlan,mod_dl_src:fa:16:3e:ec:f3:dd,output:8
#dst mac 地址為 vm1，去掉 vlan tag，修改 src mac，發到虛機table=1, n_packets=2321, n_bytes=227458, idle_age=0, priority=4,dl_vlan=2,dl_dst=fa:16:3e:30:ee:23 actions=strip_vlan,mod_dl_src:fa:16:3e:63:3b:4c,output:4
#dst mac 為 vm2，則去掉 vlan tag，修改 src mac，發到虛機table=1, n_packets=0, n_bytes=0, idle_age=2268, priority=4,dl_vlan=1,dl_dst=fa:16:3e:4a:22:ff actions=strip_vlan,mod_dl_src:fa:16:3e:ec:f3:dd,output:8table=1, n_packets=0, n_bytes=0, idle_age=9734, priority=1 actions=drop table=23, n_packets=0, n_bytes=0, idle_age=9734, priority=0 actions=drop
4.3.2 br-tun flows 主要的修改
br-tun flows 的主要修改是增加了 table 1 和 9.
- 對於將要離開本機的網絡幀：
- Table 1 （DVR process Table）： 如果網絡幀的 src mac 是本機 qrouter 上的 interface 的 mac 地址（dvr-router-intf-mac），將其修改為 DVR-compute-node-unique-mac，然后交給table 2 處理；其它的幀，交給 table 2.
table=1, n_packets=8655, n_bytes=848190, idle_age=1, priority=1,dl_vlan=1,dl_src=fa:16:3e:ec:f3:dd actions=mod_dl_src:fa:16:3f:b2:34:82,resubmit(,2) table=1, n_packets=10, n_bytes=980, idle_age=7987, priority=1,dl_vlan=2,dl_src=fa:16:3e:63:3b:4c actions=mod_dl_src:fa:16:3f:b2:34:82,resubmit(,2) table=1, n_packets=635, n_bytes=26950, idle_age=8015, priority=1,dl_vlan=1,dl_src=fa:16:3e:a9:da:b5 actions=mod_dl_src:fa:16:3f:b2:34:82,resubmit(,2)
-
- table 2：單播幀轉 table 20；多播幀轉 table 22
table=2, n_packets=8673, n_bytes=849786, idle_age=1, priority=0,dl_dst=00:00:00:00:00:00/01:00:00:00:00:00 actions=resubmit(,20) table=2, n_packets=675, n_bytes=30798, idle_age=3727, priority=0,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 actions=resubmit(,22)
-
- table 20：將 vlan id 轉化為 tunnel id，並根據處理進入本機的網絡幀的時候學習到的 mac 地址和 tunnel port，查找網絡幀的出口 tunnel port
table=20, n_packets=0, n_bytes=0, idle_age=10156, priority=2,dl_vlan=1,dl_dst=fa:16:3e:54:f8:b8 actions=strip_vlan,set_tunnel:0x4,output:3table=20, n_packets=4012, n_bytes=393176, idle_age=1, priority=2,dl_vlan=1,dl_dst=fa:16:3e:13:93:0d actions=strip_vlan,set_tunnel:0x4,output:2
-
- table 22：將 vlan id 轉化為 tunnel id，並泛洪到所有的 tunnel 端口
table=22, n_packets=8, n_bytes=1126, idle_age=11018, hard_age=5501, dl_vlan=2 actions=strip_vlan,set_tunnel:0x6,output:3,output:2table=22, n_packets=642, n_bytes=27866, idle_age=3727, hard_age=5469, dl_vlan=1 actions=strip_vlan,set_tunnel:0x4,output:3,output:2table=22, n_packets=25, n_bytes=1806, idle_age=3772, priority=0 actions=drop
- 對於進入本機的網絡幀：
- table 0：交給 table 3 處理
- table 3：只允許目的網絡為本機上的虛機所在的網絡的網絡幀，修改其 vlan id，轉 table 9
table=3, n_packets=98, n_bytes=6514, idle_age=3731, priority=1,tun_id=0x4 actions=mod_vlan_vid:1,resubmit(,9) # tunnel id 轉換為 vlan id table=3, n_packets=3830, n_bytes=375768, idle_age=1, priority=1,tun_id=0x6 actions=mod_vlan_vid:2,resubmit(,9) #tunnel id 轉換為 vlan id table=3, n_packets=0, n_bytes=0, idle_age=11238, priority=0 actions=drop
-
- Table 9 （DVR Learning blocker）：如果 src mac 是 DVR-Unique-MAC，不做 mac 學習，轉發到 patch-int；否則，轉到 table 10 做 mac 地址學習
table=9, n_packets=0, n_bytes=0, idle_age=11236, priority=1,dl_src=fa:16:3f:12:a3:38 actions=output:1 #從 network node 過來的幀，發到 br-inttable=9, n_packets=3821, n_bytes=374458, idle_age=1, priority=1,dl_src=fa:16:3f:db:6f:73 actions=output:1 #從 compute 2 node 過來的幀，發到 br-inttable=9, n_packets=107, n_bytes=7824, idle_age=3731, priority=0 actions=resubmit(,10) #其余提交 table 10 處理，進行地址學習
-
- table 10：mac 地址學習，結果存到 table 20
table=10, n_packets=107, n_bytes=7824, idle_age=3731, priority=1 actions=learn(table=20,hard_timeout=300,priority=1,NXM_OF_VLAN_TCI[0..11],NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],load:0->NXM_OF_VLAN_TCI[],load:NXM_NX_TUN_ID[]->NXM_NX_TUN_ID[],output:NXM_OF_IN_PORT[]),output:1
注意：在 table 20 中，除了自己通過 mac 地址學習學到的 mac 地址外，還需要借助 l2population 。這就是為什么 DVR 依賴於 l2population 的緣故。沒有使用的話，網絡包無法發到正確的 tunnel interface。
具體設置 OVS flows 的代碼在 setup_dvr_flows_on_integ_tun_br 函數中。更詳細的說明可以參考官方文章。
4.4 qrouter 中的ARP 表
虛機 vm1 需要通過 ARP 獲取兩種 mac 地址：
1. 當目標計算機（vm2）不在其同一個網段時，它需要獲取默認網關的 mac 地址，這個將由 qrouter 直接相應 arp 請求。
2. 當目標計算機（vm2）在其同一個網段時，它需要直接獲取 vm2 的 mac 地址。這個應該仍然是通過 ARP 廣播獲得。簡單的做法是使用 arp responder。
qrouter 在做完 vm1 的網絡包的路由后，將網絡包從 vm2 所在網段的 interface 上發出前，需要獲取 vm2 的 mac 地址。而這個是通過它查詢自身的 ARP table 獲得的。這是 compute 1 上 qrouter netns 中的 ip neighbour 表：
root@compute1:/home/s1# ip netns exec qrouter-e8f12f7a-6938-4e65-88c4-97e4cb211b27 ip neigh
90.1.180.6 dev qr-f849ae46-48 lladdr fa:16:3e:13:93:0d PERMANENT
81.1.180.10 dev qr-517bdba3-b1 lladdr fa:16:3e:c0:8f:2c PERMANENT
90.1.180.3 dev qr-e47fca31-db lladdr fa:16:3e:69:92:30 PERMANENT
這里面可以看到大量的 PERMANENT MAC 地址。這是因為，L3 Agent 配置 DVR Router 的時候，它通過 RPC 從 neturon server 獲取該 router 各 interface 的 subnet 中獲取所有虛機的 MAC 地址。當一個 subnet 被加到 DVR Router 的時候，每個相關的 L3 Agent 都會被通知到，然后它通過 RPC 獲取各 MAC 地址。當一個新的 port 被創建，或者 port 的 MAC 有更新的時候，所有相關的 L3 Agent 會被通知到去更新 ARP 表。
通過該由 L3 Agent 動態維護的 ARP 表，qrouter 就能直接查到它要通信的 interface 的 MAC 地址了，而不需要通過廣播的方式去被動獲取。具體原因是：
Why all of this complexity? Remember that the router’s MAC addresses are present on all hosts and cannot leave the host. If a router scheduled on host 1 generated an ARP request for a port scheduled on host 2, host 2 would receive the message and its virtual switches would suddenly re-learn a MAC they supposedly already know to be connected to br-int. They would see it coming from a tunnel connected to br-tun!
大致的更新過程為：
- 每個L2 Agent 進程循環檢查其管理的 port 的狀態
- 當 port 狀態由 down 變為 up 時，它通過 RPC 通知 neutron server 該變化，neutron server 然后發出 fanout 通知其他的 L2 agent 去添加 arp entry （add_arp_entry），再調用 ip neigh replace方法在 qrouter network namespace 中 增加一個 arp entry
- 當 port 狀態由 up 變為 down 時，它通過 RPC 通知 neutron server 該變化，neutron server 然后發出 fanout 通知其他的 L2 agent 去添加 delete entry （del_arp_entry），再調用 ip neigh del 方法在 qrouter network namespace 中 刪除該 arp entry
4.5 ip rule 和 route 操作
4.5.1 增加一個 internal subnet 時
在 qrouter namespace 上：
（1）計算該 subnet cidr（81.1.180.1/24）的 index 1359066113，作為新增 ip rule 的優先級和路由表的名稱。
（2）增加 default gateway，運行 ['ip route replace default via 81.1.180.17 dev qr-517bdba3-b1 table 1359066113]。這里的 81.1.180.17 正是 snat namespace 的 IP。
（3）增加 ip rule， 允許 [ip rule add from 81.1.180.1/24 lookup 1359066113 priority 1359066113]。這樣就將該 subnet 中的虛機的網絡幀轉到 route table
（4）執行 ip netns exec qrouter-e8f12f7a-6938-4e65-88c4-97e4cb211b27 sysctl -w net.ipv4.conf.qr-517bdba3-b1.send_redirects=0
效果如下：
root@compute1:/home/s1# ip netns exec qrouter-e8f12f7a-6938-4e65-88c4-97e4cb211b27 ip rule
0: from all lookup local
32766: from all lookup main
32767: from all lookup default
1359066113: from 81.1.180.1/24 lookup 1359066113
root@compute1:/home/s1# ip netns exec qrouter-e8f12f7a-6938-4e65-88c4-97e4cb211b27 ip route list table 1359066113
default via 81.1.180.17 dev qr-517bdba3-b1
這樣，當虛機還沒有配置浮動IP時，訪問外網的話，網絡幀的路線為：vm ---- qrouter subnet 1 interface --- SNAT ---- external port ----- pc
因此，當 router 上連接有多個 subnet 時，qrouter 中也有相應數量的 ip rule 和 routing table：
root@compute1:/home/s1# ip netns exec qrouter-e8f12f7a-6938-4e65-88c4-97e4cb211b27 ip rule 0: from all lookup local 32766: from all lookup main 32767: from all lookup default 1359066113: from 81.1.180.1/24 lookup 1359066113 1510061057: from 90.1.180.1/24 lookup 1510061057 1526838273: from 91.1.180.1/24 lookup 1526838273
4.5.2 給虛機綁定浮動 IP 時
在 qrouter namespace 中：
（1）增加 ip rule，通過運行 ['add', 'from', u'81.1.180.18', 'lookup', 16, 'priority', 32768]，其中，ID 16 為寫死的，其優先級是從 32768 開始到 36768 這個區間內依次分配。
（2）在路由表 16 中添加路由項 default via 169.254.31.239 dev rfp-e8f12f7a-6。這使得虛機訪問外網的網絡包會通過 rfp-e8f12f7a-6 發到 169.254.31.239。而這個 IP 正是 fip 上 pfr 端口的IP。
在 fip namespace 中：
（1）增加 route：192.168.1.0/24 dev fg-6b744484-88 proto kernel scope link src 192.168.1.119。這使得訪問外網機器的網絡包能從 fg-6b744484-88 出去。
（2）增加 route：192.168.1.116 via 169.254.31.238 dev fpr-e8f12f7a-6。使得訪問虛機的網絡包會發給 169.254.31.238，進入 qrouter。這個 router 上的每個浮動 IP 有這么一條 route。
配置了兩個浮動 IP 的情況下是這樣的結果：
root@compute1:/home/s1# ip netns exec qrouter-e8f12f7a-6938-4e65-88c4-97e4cb211b27 ip rule
32768: from 81.1.180.18 lookup 16 #去 fip 的
32769: from 90.1.180.8 lookup 16 #去 fip 的
1359066113: from 81.1.180.1/24 lookup 1359066113 #去 snat 的
1510061057: from 90.1.180.1/24 lookup 1510061057 #去 snat 的
root@compute1:/home/s1# ip netns exec qrouter-e8f12f7a-6938-4e65-88c4-97e4cb211b27 ip route list table 16
default via 169.254.31.239 dev rfp-e8f12f7a-6 # route 是一樣的
root@compute1:/home/s1# ip netns exec fip-557e9f0c-9c66-46da-b289-218d49c218d2 ip route
default via 192.168.1.1 dev fg-6b744484-88
169.254.31.238/31 dev fpr-e8f12f7a-6 proto kernel scope link src 169.254.31.239
192.168.1.0/24 dev fg-6b744484-88 proto kernel scope link src 192.168.1.119
192.168.1.104 via 169.254.31.238 dev fpr-e8f12f7a-6 #每個浮動 IP 一個 route item
192.168.1.116 via 169.254.31.238 dev fpr-e8f12f7a-6
這里能看到 qroute 的 ip rule 上，針對一個虛機/子網，有兩條 rule，一條查路由表 16 到 fip，另一條查表到 snat。但是，在有浮動 IP 的情況下，前一條策略的優先級數值將小於后后一條的，這就決定了查路由表 16，數據包走 fip。
4.5.3 qrouter 的 main 路由表
main 路由表是為虛擬子網服務的，每個 subnet 對應一條路由規則，使得目的為每個 subnet 的網絡包從指定的 qrouter 的 qr interface 上發出。
root@compute1:/home/s1# ip netns exec qrouter-e8f12f7a-6938-4e65-88c4-97e4cb211b27 ip route
81.1.180.0/24 dev qr-517bdba3-b1 proto kernel scope link src 81.1.180.1 #為到子網 1 中的虛機的網絡包做路由
90.1.180.0/24 dev qr-f849ae46-48 proto kernel scope link src 90.1.180.1 #為到子網 2 中的虛機的網絡包做路由
91.1.180.0/24 dev qr-e47fca31-db proto kernel scope link src 91.1.180.1
169.254.31.238/31 dev rfp-e8f12f7a-6 proto kernel scope link src 169.254.31.238 #為從 fip 進來的外網訪問內部虛機的網絡包做路由
5. Neutron 其它服務與 DVR
5.1 FWaas DVR
DVR 與傳統的 FWaas 不兼容，因為它作用於neuron 網絡節點上的 virtual router，過濾進出租戶網絡的網絡包。傳統的 FWaas 可以參考我的另一篇文章。
DVR 實現后，FWaas 需要做相應的修改。
官方文檔在這里：
https://wiki.openstack.org/wiki/Neutron/FWaaS/FWaaS-DVR
Spec：https://review.openstack.org/#/c/106225/9/specs/juno/neutron-dvr-fwaas.rst
目標：FWaas 保持對 南-北流量做防火牆，而不影響東-西流量。
做法：Neutron 網絡節點上的 FWaas Agent 安裝在 SNAT network namespace 中；計算和網絡節點上的 FWaas Agent 安裝在 qrouter network namespace 中。
5.2 VPNaas DVR
Juno 版本中 VPNaas 不支持 DVR，只支持傳統的 router。Kilo 版本中會實現 VPNaas 對 DVR 的支持。新的 VPN 服務只會在 dvr_snat 節點上的 snat namespace 上運行。
5.3 LBaas 與 DVR
兩者之間沒有相互依賴關系，所以 DVR 對 LBaas 沒有影響。
總體情況：
6. 后續版本中 DVR 開發
6.1 Kilo 版本中
- VPNaaS 對 DVR 的支持
- 從傳統 router 遷移到 DVR router
- 網絡節點上 HA + DVR 支持
- VLAN 支持
6.2 Liberty 版本中
- L3 Agent 重構
- 分布式 DHCP
- 性能調優
- 分布式 SNAT
從第五和第六兩個章節也可以看出，Juno 版本才添加的 DVR 功能還很不完善，難以滿足生產環境的使用要求，主要是因為它還不支持目前實際部署中應該很廣泛的 VLAN 組網模式，以及無法解決 HA 和 DVR 共存的問題。可喜的是這兩個主要問題會在 K 版本中解決，因此 K 版本中的 DVR 至少可以用來做測試用了。等到 L 版本，實現分布式 DHCP 和 SNAT，以及性能優化以后，離生產環境的要求基本就差不多了。
參考鏈接：
- http://assafmuller.com/
- http://assafmuller.com/2015/04/15/distributed-virtual-routing-snat/
- http://bingotree.cn/?p=706
- https://docs.google.com/document/d/1jCmraZGirmXq5V1MtRqhjdZCbUfiwBhRkUjDXGt5QUQ/edit
- http://assafmuller.com/2015/04/15/distributed-virtual-routing-overview-and-eastwest-routing/
- http://greenstack.die.upm.es/2015/04/15/distributed-virtual-routing-overview-and-eastwest-routing/
- Architectural Overview of Distributed Virtual Routers in OpenStack Neutron by Vivekanandan Narasimhan
- Openstack 官網
歡迎大家關注我的個人公眾號：
