接上節，啟動 neutron router 后 instance c1 終於拿到了 metadata, 從下面 c1 的啟動日志可知：
c1 所認為的 metadata 服務地址是 169.254.169.254，端口為 80。我們在 c1 中嘗試訪問一下 metadata。
確實能夠拿到 metadata。但我們知道 nova-api-metadata 是運行在控制節點上的，IP並不是 169.254.169.254，這是怎么實現的呢？下面我們分析一下這個過程。
從 c1 的路由表得訪問 169.254.169.254 的請求會走 17.17.17.1。
17.17.17.1 實際上就是 test_router 在 test_net 上的 interface IP。這條路由是 OpenStack 自動添加到 instance 中的，這樣就將 metadata 的請求轉發到 neutron router。
ip netns 是管理 linux network namespace 的命令，如果對 namespace 不熟悉，可參考教程前面相關章節。
test_router 接收到 c1 的請求，會通過 iptable 規則轉發到 9697 端口。
9697 端口是干嘛的？這是 neutron-ns-metadata-proxy 的監聽端口。
到這里我們可以把思路重新理一下了：
-
instance 通過預定義的
169.254.169.254請求 metadata。
-
請求被轉發到 neutron router。
-
router 將請求轉發給 neutron-ns-metadata-proxy。
-
再后面就簡單了：neutron-ns-metadata-proxy 將請求通過 unix domain socket 發給 neutron-metadata-agent，后者再通過管理網絡發給 nova-api-metadata。
OpenStack 默認通過 l3-agent 創建和管理 neutron-ns-metadata-proxy。但不是所有環境都有 l3-agent，比如直接用物理 router 的場景。這時就需要讓 dhcp-agent 來管理 neutron-ns-metadata-proxy。
下一節我們分析 dhcp-agent 如何處理 metadata 請求。
