正因為Controller有所有交換機的拓撲及位置信息，此時Controller會給全網中每臺SDN交換機都發送一個10.0.0.0/8網段的ARP請求消息，來請求10.0.0.2的MAC地址。但源IP并非10.0.0.1，而是Controller的網關地址，此處為10.0.0.254。此時報文均為packet-out，即通過Controller手工泛洪，但此泛洪是有選擇性的，只針對同網段（10.0.0.0/8）

所有交換機都能收到此ARP單播請求，而只有Switch B會做出回應，因為H2接在Switch B下游。此時通過packet-in，所有SDN交換機會將此ARP泛洪發送到同網段的端口。

H2收到此時的ARP請求，正常做出回應。

Switch B收到H2的ARP響應，無腦上送到Controller。Controller收到ARP響應，發現正是前面發出的ARP請求的響應報文。記錄此時的H2位置信息及ARP信息。

Controller通過Openflow將ARP響應回應給Switch A，Switch A將報文回送給H1。

Controller已經完整知道SwitchA/SwitchB/H1/H2的位置信息及MAC/ARP信息。Switch A/H1知道完整的ARP/MAC信息。而SwitchB也有H1/H2的完整IP。唯獨H2此時只知道H1的IP，而不知道H1的MAC。

H1的整個ARP請求過程已經完成。接下來要輸送ICMP請求報文。報文經由Switch A正常輸送到H2（此時是實際轉發流量，而且Switch A已有完整轉發路徑，不需要再上送Controller）

H2收到ICMP報文，想要回應，但是沒有H1的MAC，需要再次做ARP請求。此時H2請求H1的MAC地址，報文被Switch B上送Controller，Controller已有H1的MAC，則Controller做出回應，將H1的MAC回應給H2。

H2收到ARP，則整個過程完整。回應ICMP報文。整個業務流打通。

可以看到，最關鍵的應該是第三步，即Controller發送偽裝ARP報文給全局同網段交換機，以此來實現ARP廣播的同樣效果。但也正是這樣一個看似合理的安全行為，帶來了很多不安全的隱患。可以想象，Controller有幾種方式可以獲取終端主機的MAC情況：1.通過免費ARP的方式、2.定時申請下游終端的MAC方式，都可以保證對下游終端MAC的始終更新。

但同樣，集中Controller的方式也帶來了單點安全的風險考慮，一旦一臺下游主機中毒，不斷變化自己的MAC不斷做出更新動作，此時會極大消耗Controller的資源，形成DOS攻擊。同樣，Controller的安全如果不是很堅固，則一旦被攻破，所有終端信息一覽無余。