接上節，啟動 neutron router 後 instance c1 終于拿到了 metadata, 從下面 c1 的啟動日志可知：
c1 所認為的 metadata 服務位址是 169.254.169.254，端口為 80。我們在 c1 中嘗試通路一下 metadata。
确實能夠拿到 metadata。但我們知道 nova-api-metadata 是運作在控制節點上的，IP并不是 <code>169.254.169.254</code>，這是怎麼實作的呢？下面我們分析一下這個過程。
從 <code>c1</code> 的路由表得通路 <code>169.254.169.254</code> 的請求會走 <code>17.17.17.1</code>。
<code>17.17.17.1</code> 實際上就是 <code>test_router</code> 在 <code>test_net</code> 上的 interface IP。這條路由是 OpenStack 自動添加到 instance 中的，這樣就将 metadata 的請求轉發到 neutron router。
<code>ip netns</code> 是管理 linux network namespace 的指令，如果對 namespace 不熟悉，可參考教程前面相關章節。
<code>test_router</code> 接收到 <code>c1</code> 的請求，會通過 iptable 規則轉發到 9697 端口。
9697 端口是幹嘛的？這是 neutron-ns-metadata-proxy 的監聽端口。
到這裡我們可以把思路重新理一下了：
instance 通過預定義的 <code>169.254.169.254</code> 請求 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 請求。