為了提高neutron網絡服務的魯棒性與性能，OpenStack從J版開始正式加入的DVR(Distributed Virtual Router)服務，它将原本集中在網絡節點的部分服務分散到了計算節點上。
在該模式下，同租戶的跨網段路由在計算節點之間直接完成，無需網絡節點的參與。SNAT服務仍有網絡節點集中化的處理。Floating服務則可以選擇在計算節點分布式地處理，也可以選擇在網絡節點中心化的處理。
DVR在帶來網絡服務魯棒性與性能提升的同時，也帶來了一些缺陷。東西向的FWAAS服務變得無法實作，具體參考“連結”。簡單來說就是FWAAS功能依賴于在同命名空間的vrouter下看到雙向（有狀态）的進出兩條流。現在部署DVR功能後的東西向通信，打破了這條規則。下面将對OpenStack Queens版本的 DVR部署進行闡述分析。
部署
準備
已經部署好的基于租戶網絡是vxlan的OpenStack環境
控制節點配置
檔案：neutron.conf
router_distributed = true
重新開機服務
systemctl restart neutron-server.service
網絡節點配置
檔案：openvswitch_agent.ini
l2_population=true
enable_distributed_routing = true
檔案：l3_agent.ini
agent_mode =dvr_snat
external_network_bridge 留白
重新開機服務
systemctl restart openvswitch.service
systemctl restart neutron-openvswitch-agent.service
systemctl restart neutron-l3-agent.service
systemctl restart neutron-dhcp-agent.service
systemctl restart neutron-metadata-agent.service
計算節點配置
安裝neutron相關服務
yum install openstack-neutron
修改核心配置
echo '
net.ipv4.conf.all.rp_filter=0
net.ipv4.conf.default.rp_filter=0
net.bridge.bridge-nf-call-iptables=1
net.bridge.bridge-nf-call-ip6tables=1
'>>/etc/sysctl.conf
sysctl -p
修改配置dhcp_agent.ini,l3_agent.ini,metadata_agent.ini這3個檔案。
檔案：openvswitch_agent.ini
l2_population=true
enable_distributed_routing = true
檔案：l3_agent.ini
agent_mode =dvr
external_network_bridge 留白
添加對外網橋，eth_TBD,IP_TBD要根據實際環境而定
echo '#
ovs-vsctl add-br br-ex
ovs-vsctl add-port br-ex eth_TBD
ovs-vsctl show
ifconfig eth_TBD 0.0.0.0
ifconfig br-ex IP_TBD/24
#'>>/etc/rc.local
chmod +x /etc/rc.d/rc.local ; tail -n 8 /etc/rc.local |bash
重新開機服務
systemctl restart openvswitch.service
systemctl restart neutron-openvswitch-agent.service
systemctl restart neutron-l3-agent.service
systemctl restart neutron-dhcp-agent.service
systemctl restart neutron-metadata-agent.service
驗證操作
在控制節點上檢視network agent。
實驗分析
部署虛機與網絡
總覽
本着“無圖無真相””一圖勝千言”的原則，在接下來的分析中争取多放圖，少廢話。
在部署好DVR，虛機，網絡後，整個系統的網絡組成及各節點上的功能分布如下圖所示。
同節點東西向
跨節點東西向
從上表中我們可以直覺的看到跨節點的路由通信過程。原理與傳統路由功能基本一緻。唯一的差別在進入VXLAN隧道前把原本網關MAC替換成DVR_HOST_MAC,在出VXLAN隧道後又把DVR_HOST_MAC換回網關MAC。具體原理我們将在“如何解決各節點上DVR的沖突”這一小節給出解釋。
進入qrouter這個命名空間就使用linux的進階路由功能來完成路由過程。（引用《深入了解openstack neutron》中一句話：“Linux建立router并沒有像建立虛機bridge那樣，有一個直接的指令brctl，而且它間接指令也沒有，不能建立虛拟路由器……因為它就是路由器（router）”）。在compute-1計算節點上我們可以觀察到如下圖所示資訊。不同網段該從哪個qr口出去，不同neighbor的IP,MAC的對應關系都是有neutron事先設定好的。
NAT
這裡遇到了和上一小節同樣的問題。具體原理我們将在“如何解決各節點上DVR的沖突”這一小節給出解釋。
FloatingIP
如何解決各節點上DVR的沖突
在各節點上的vrouter其qr口的IP,MAC都是圖中各network：router_interface_distributed Port的IP,MAC.在這種情況下，各節點中的VM是如何正确的找到同主控端下正确的vrouter及正确的網關的呢？
讓我們看一下br-tun上的部分流表
從圖中可知，br-int中進入br-tun中的所有流量都會經過table 1的篩選過濾。注意流表項5、6、7、8的比對項。這4條流表把所有查詢網關MAC的ARP廣播封包丢棄，把所有目的MAC是網關MAC的未知單點傳播封包都丢棄。這裡就確定了一個主控端内的VM隻能感覺到本主控端内的vrouter，或者認為一些資料包是同主控端内的vrouter給其轉送資料包。
但是經過上面描述的處理後，那麼三層轉發封包又如何能到達其他節點呢？這裡我們看一段社群給出的說明。
在初始化期間，OVS agent需要知道其持有的唯一的DVR MAC位址，以此在br-tun，br-int中輸入正确的流表項。出于這個目的，L2 agent通過RPC的方式調用ML2 plugin中的get_dvr_mac_address(host_id)函數。
讓我們去控制節點看看這個dvr_mac_address又是什麼。在Tables_in_neutron中找到一張名為dvr_host_macs的表，查詢其中的内容我們是不是又發現了熟悉的MAC。這些都是neutron配置設定的，全局唯一的，與各節點一一對應的MAC位址。如果有心的話在配置控制節點的neutron.conf檔案時，可以看到有個名為”dvr_base_mac”配置項，該項可以自定義DVR MAC的字首高位。