OpenStack 默認通過 l3-agent 創建和管理 neutron-ns-metadata-proxy，進而與 nova-metadata-api 通信。但不是所有環境都有 l3-agent，比如直接用物理 router 的場景。這時就需要走另一條路：讓 dhcp-agent 來創建和管理 neutron-ns-metadata-proxy。
打開 /etc/neutron/dhcp_agent.ini，設置 force_metadata
重啟 dhcp-agent 后，可以看到控制節點上多了一個 neutron-ns-metadata-proxy 進程。
此進程通過 --network_id 關聯到 test_net，這就是 dhcp-agent 啟動的 neutron-ns-metadata-proxy，用於接收 test_net 網絡上 instance 的 metadata 請求。每一個 network 都有一個與之對應的 neutron-ns-metadata-proxy。
重啟 instance c1，查看路由表。
請注意，現在訪問 169.254.169.254 的路由已由之前的 17.17.17.1變為 17.17.17.2。這里的 17.17.17.2 是 dhcp-agent 在test_net 上的 IP。這條路由是由 dhcp-agent 添加進去的。正是因為這條路由的存在，即便 l3-agent 與 dhcp-agent 同時提供 neutron-ns-metadata-proxy 服務，metadata 請求也只會發送給 dhcp-agent。
同時我們也看到，dhcp-agent 已經將 IP 169.254.169.254 配置到了自己身上。也就是說：c1 訪問 metadata 的請求 http://169.254.169.254 實際上是發送到了 dhcp-agent 的 80 端口。而監聽 80 端口的正是 dhcp-agent 啟動的 neutron-ns-metadata-proxy 進程。
后面的數據流向就與 l3-agent 的場景一樣了：neutron-ns-metadata-proxy 將請求通過 unix domain socket 發給 neutron-metadata-agent，后者再通過管理網絡發給 nova-api-metadata。
到這里，我們已經分別討論了通過 l3-agent 和 dhcp-agent 訪問 metadata 的實現方法。對於 169.254.169.254：
-
l3-agent 用 iptables 規則來轉發。
-
dhcp-agent 則是將此 IP 配置到自己的 interface 上。
不知道大家有沒有這樣一個疑問：
nova-api-metadata 是怎么知道應該返回哪個 instance 的 metadata？c1 只是向 169.254.169.254 發送了一個 http 請求，nova-api-metadata 怎么就知道應該返回 c1 的 metadata 呢？
下節咱們詳細分析這個問題。
