最近有個需求，需要把公網IP映射到虛擬機上。需求其實很簡單，利用Neutron的原生FloatingIP功能就能解決，但是真正解決的時候還是耗了不少時間。大家都是知道公有雲和私有雲最本質的區別不是虛擬化，也不是存儲，而是網絡。公有雲的網絡龐大而復雜，如何把公網IP正確的映射到用戶的虛擬機上，背後還是包含了眾多的網絡技術。對於大部分利用OpenStack搭建私有雲的企業，壹般采用Flat和Vlan的組網模型，網關都在物理交換機上，很少利用L3-agent來做VRouter。所以網絡相對簡單，排查起來也比較容易。我的也是基於Vlan的組網架構，在此基礎上創建VRouter來綁定FloatingIP。
經過這兩天的折騰，終於把公網IP映射到虛擬機上，中途遇到不少坑，有自身原因也有OS本身的坑，總之沒有想象中的容易。
在操作之前簡單介紹下我的環境，1臺控制+網絡節點，9臺計算節點。由於映射公網IP地址需求比較少，L3-agent就只部署到網絡節點上。
網絡節點網卡分配如下：
Neutron支持的服務如下：
這裏面包括LBAAS，FWAAS，ROUTER和QOS等特性。
ml2沒什麽的改的，只需要在加載ml2驅動的時候包含vlan和falt就可以了，在這裏配置
還需要定義壹下flat的網絡類型
l3的坑多，最開始我用的默認配置，結果出現壹些摸不著頭腦的問題，例如下面這樣。
1. VRouter綁定的Port網卡 qg-xxxx 和 qr-xxxx 都橋接在 br-int 下
結果發現壹個隱藏的坑是 external_network_bridge 默認配置項是空的，這導致router綁定都port都放在br-int下。
解決也很簡單，如下配置就好了。
2. Router防火墻
由於開啟了防火墻，還要需要在L3的擴展裏面加上fwaas，如下：
1. 創建NetWork
2. 創建Subnet
tips:在公網IP資源稀缺情況下sunbet不要開啟dhcp,避免不必要的浪費。
3. 創建Router
4. 設置Router網關
這裏external網絡可以綁定固定ip，只需要引入 --fixed-ip subnet_id=SUBNET,ip_address=IP_ADDR 就可以了。
5. Router綁定內網Port
完成以上工作就能在網絡節點的ovs和namespace中看到vrouter的信息了。
1. 創建浮動IP
也可以手動創建固定IP的,加入 --fixed-ip-address 參數即可。
2. 綁定浮動IP到虛擬機
綁定成功後在Router的命名空間裏面可以看到以下內容：
這裏看到其實Floating IP是被綁定到qg-xxxx網卡上。我們都知道，浮動IP是通過DNAT轉發到虛擬機實際的IP上。
接下來就看看iptables的規則
如果這樣就解決了，那也太簡單，這篇文章也沒任何意義。
剛開始我以為綁定好Floating IP後，就能通過公網登錄虛擬機。不！其實是不通的。
問題的表象是：
1. 本地ping不通公網的< Floating IP >
2. 本地能ping通< External Gateway >
3. 在Router的NS裏面也ping不通< Floating IP >
4. 在Router的NS裏面能ping通公網的物理網關
1. 剛開始以為是ovs的創建的port問題，於是手動通過ovs創建壹個網卡綁定公網ip，發現問題不在於此。
過程如下：
結果發現配置在test網卡上的 公網IP01 和 公網IP02 都能在本地ping通，說明問題不在ovs的端口創建上。
2. 防火墻
在防火墻上創建了icmp的規則，仍然不通。
3. Router的iptables
我在這裏清空了VRouter NS裏的nat表，發現本地能夠ping通< Floating IP >了，說明本地到VRouter的ovs端口的鏈路是正常的，問題應該出在轉發上。
於是恢復nat表規則，果然< Floating IP >又ping不通了。
4. 虛擬機抓包
在物理機上抓虛擬機網卡，發現ping < Floating IP >。虛擬機能夠響應icmp請求。
這裏看到了虛擬機reply了icmp的請求，但是我本地ping並沒有回包，說明問題出在了網關上。
5. 重置網關
問題已經清楚了，虛擬機在回包的時候發到物理交換機的網關了，VRouter沒有收到回包，當然ping不通了。解決這個問題比較簡單。
在虛擬機裏面把默認網關指向router裏的< Privetnet Gateway >，這個時候在本地到Floating IP的鏈路就通了。也可以通過ssh < Floating IP >登錄到虛擬機。
雖然能夠通過Floating IP訪問虛擬機了，但是之前虛擬機的默認網關在物理機交換機上，是和公司內網打通的。由於虛擬機改了默認網關到虛擬機路由器，而VRouter裏面默認網關是< 公網網關 >，所以此時虛擬機網絡不通。
剛開始我有兩個解決思路是：
1. 通過iptables標識來源報文，通過標識轉發流量
這個方法開始我覺得理論上是可行的，但壹直沒測試成功，便放棄了。
2. 通過snat隱藏公網ip
這個方法可行，但是這樣對虛擬機來說就隱藏了來源的公網地址，這不符合我的需求，放棄了。
正確的解決思路
上面兩個方法我壹開始就想多了，其實簡單點，直接通過路由方式就能滿足需求，但是需要引入人工配置，不太方便。
這樣虛擬機到內網環境就通了，但是內網到虛擬機仍然不通。
這樣虛擬機的內網就打通了，同時公網的訪問就通過默認的VRouter出去。
至此，虛擬機內網和公網的網絡就打通了。
這麽蛋疼的網絡結構主要原因是二層的網關引入了物理交換機，造成VRouter綁定虛擬機網絡時不能夠充當網關角色。
這個問題困擾我兩臺，其實總結了下，有兩點需要人工幹預：
感想
由於在未引入DVR時，Neutron的南北流量是通過網絡節點的router出去的，在大流量的情況下會成為瓶頸，所以在開始做OpenStack網絡規劃的時候就沒有考慮采用L3-Agent，這導致後來在做Floating IP的時候給自己挖了坑。
其實說白了，還是要看自己公司的網絡需求和網絡的運維成本。