公司生產機房最近淘汰下來一批裝置，不算太舊，普遍CPU兩顆兩核，少數四顆四核，但其中已經有若干臺主機安裝不了CentOS7的系統了。因為主機型號太舊，CentOS7已經不提供磁碟驅動的支援了。所以只好將就著裝成了CentOS6.7。為了更好得發揮餘熱，著手部署了一套OpenStack系統，版本只能選用Ice House，因為受制於OS的版本。

系統的架構基本上是：

一個控制節點

一個網路節點

四個計算節點

以上六個主機節點全部帶磁碟儲存，部署GlusterFS系統，與Cinder整合提供雲硬碟服務。

使用Neutron實現OpenStack網路服務時，發現雲主機無法獲取到DHCP地址。

問題分析：

1、DHCP Server是執行在網路節點上的，通過dnsmasq發放地址，因此雲主機必須與網路節點上的DHCP服務能夠通訊；

2、雲主機執行在計算節點上，使用GRE隨道通訊與網路節點進行互動，每新建一個雲主機就會有一個新的專用的通訊隧道的建立，在隧道兩側的網路介面名稱基本上都是命令為類似於br-tun的形式；

3、隧道介面br-tun在收發來自隧道的資料後，進行了格式轉換，轉發給了br-int網路介面，翻譯為雲主機和網路節點的IP網路能夠識別的格式；

4、使用tcpdump在網路節點和計算節點上，針對br-int介面進行抓包，應該能抓到雙方進行DHCP互動的資料包；

#tcpdump -i br-int
 

使用瀏覽器登入dashboard管理平臺，進入測試使用的雲主機Cirros中，手工執行獲取dhcp地址的命令：

#sudo cirros-dhcpc up eth0

在計算節點上，立即就抓到了發出dhcp請求的廣播資料包，證明雲主機系統和計算節點網路正常。

而網路節點的br-int介面始終沒獲取到dhcp廣播包。於是直接對網路節點的隧道通訊網絡卡進行抓包：

#tcpdump -i eth1

5、分析

dhcp請求已經進入了網路節點，但是沒能經由隧道介面轉給br-int內網介面，因此雲主機的dhcp請求得不到響應。

在確認了網路節點的隧道介面br-tun和內網介面br-int的埠對映無誤後，認為DHCP請求是卡在了網路節點的系統層面，即eth1可以拿到，br-tun和br-int不能拿到，除非是網路節點的iptables策略把資料包攔住了。

借用一張OpenStack官網的架構圖來說明一下系統與網路部署結構：

6、我們看一下網路節點此時的iptables規則如下

[[email protected] ~]# iptables --list
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
neutron-openvswi-INPUT  all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED 
ACCEPT     icmp --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:ssh 
REJECT     all  --  anywhere             anywhere            reject-with icmp-host-prohibited 

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
neutron-filter-top  all  --  anywhere             anywhere            
neutron-openvswi-FORWARD  all  --  anywhere             anywhere            
REJECT     all  --  anywhere             anywhere            reject-with icmp-host-prohibited 

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
neutron-filter-top  all  --  anywhere             anywhere            
neutron-openvswi-OUTPUT  all  --  anywhere             anywhere            

Chain neutron-filter-top (2 references)
target     prot opt source               destination         
neutron-openvswi-local  all  --  anywhere             anywhere            

Chain neutron-openvswi-FORWARD (1 references)
target     prot opt source               destination         

Chain neutron-openvswi-INPUT (1 references)
target     prot opt source               destination         

Chain neutron-openvswi-OUTPUT (1 references)
target     prot opt source               destination         

Chain neutron-openvswi-local (1 references)
target     prot opt source               destination         

Chain neutron-openvswi-sg-chain (0 references)
target     prot opt source               destination         

Chain neutron-openvswi-sg-fallback (0 references)
target     prot opt source               destination         
DROP       all  --  anywhere             anywhere

而neutron-openvswi-INPUT鏈正是處理網路節點的OVS虛擬交換機資料通訊的入口策略。

我們繼續向下看neutron-openvswi-INPUT鏈有哪些規則。奇怪的是規則為空。按上下文的理解，這裡的規則為空，應該理解為全部ACCEPT。事實是這樣嗎？

為了驗證這一點，我們可以手工針對neutron-openvswi-INPUT鏈加一條明確的接收全部進來的資料包的規則：

iptables -A neutron-openvswi-INPUT -p all -j ACCEPT

再對網路節點的br-int介面抓包，重複雲主機獲取DHCP的操作，馬上就抓到了進入網路節點br-int子網的DHCP廣播包了。

7、結論與推測

網路節點的iptables規則，是由openvswitch服務動態維護的。上述新增的neutron-openvswi-INPUT鏈也正是啟動ovs服務後，動態生成的。根據連結串列處理邏輯，不需要顯示的設定這樣一條接受資料包的規則，也應該可以實現設計中的網路通訊能力。而事實卻不是這樣的。我沒有在更多的linux系統和版本上進行測試，至少在CentOS6.7上，必須手工增加一條連結串列規則才行。

重啟openvswitch服務後，手工加的這條規則會被清除掉。為了容易維護，可以先使用service iptables save把規則儲存至檔案中去。

在以後重啟openvswitch服務後，立即執行一次service iptables reload即可。