相信不少兄弟的SDN啟蒙都是各種高大上的論文中五花八門的概念和應(yīng)用，等到真把開(kāi)源控制器和mininet裝好，要開(kāi)始干活了，才發(fā)現(xiàn)什么traffic engineering, 什么consistent update，根本不是那么回事兒。大家要處理的第一個(gè)包甚至都不是TCP，而是ARP，而且還是廣播!這里有兄弟可能會(huì)想到DHCP，LLDP，甚至?xí)氲絀Pv6的鄰居發(fā)現(xiàn)，博主會(huì)在以后的文章中詳細(xì)討論它們，這次只講ARP。

SDN控制器管理的是由一些交換機(jī)(包括OVS和物理交換機(jī))構(gòu)成的網(wǎng)絡(luò)而不是網(wǎng)絡(luò)邊緣的服務(wù)器(包括bare metal server和vm)，但是SDN控制器在proactive的編輯各種表的時(shí)候又需要知道服務(wù)器在網(wǎng)絡(luò)當(dāng)中的位置。ARP幾乎成為最好的甚至是唯一的獲取這些信息的渠道(IPv6鄰居發(fā)現(xiàn)是另外一個(gè)話題)，因?yàn)閺腁RP我們至少可以學(xué)到兩件事情：第一，每一個(gè)mac究竟出現(xiàn)在網(wǎng)絡(luò)中哪臺(tái)交換機(jī)的哪個(gè)端口。第二，每一個(gè)mac上究竟有哪些IP地址。

也許有兄弟會(huì)問(wèn)：我們可以通過(guò)服務(wù)器發(fā)出的任何二層或者三層的報(bào)文來(lái)學(xué)到這兩件事情，為什么一定是ARP呢?答案有三：首先，既然ARP是每一臺(tái)服務(wù)器發(fā)出的幾乎第一個(gè)報(bào)文，我們?yōu)槭裁床恢苯訌倪@個(gè)報(bào)文中學(xué)到以上的信息呢?既然做proactive的SDN，那就應(yīng)該在第一時(shí)間學(xué)習(xí)網(wǎng)絡(luò)中服務(wù)器的位置。其次，如果我們的SDN網(wǎng)絡(luò)連ARP都沒(méi)有處理好，服務(wù)器都沒(méi)法收到ARP reply，那么也就沒(méi)有后面的其他報(bào)文了。第三，也是最重要的原因：我們其實(shí)并不知道網(wǎng)絡(luò)邊緣的服務(wù)器是什么設(shè)備，它可能是一個(gè)一般意義上的服務(wù)器，也可能是一個(gè)防火墻，或者是一個(gè)第三方的路由器。如果我們?cè)赟DN網(wǎng)絡(luò)邊緣看到了一個(gè)三層的報(bào)文，并且簡(jiǎn)單的認(rèn)為這個(gè)報(bào)文的src mac和src IP來(lái)自同樣一臺(tái)服務(wù)器，那么就錯(cuò)大了。

我們不妨拿傳統(tǒng)的交換機(jī)和SDN控制器管理的網(wǎng)絡(luò)做個(gè)類比。在傳統(tǒng)的交換機(jī)上，mac learning是一個(gè)非常簡(jiǎn)單的過(guò)程：我在port1上看到了mac1，那么交換機(jī)就有了一個(gè)二層的表項(xiàng)：到mac1走port1。在SDN的世界里，并沒(méi)有什么本質(zhì)的不同：我們?cè)趕witch1 port1上看到了mac1，那么到mac1就走switch1 port1。唯一的不同是：傳統(tǒng)交換機(jī)的學(xué)習(xí)就發(fā)生在交換機(jī)上。而在SDN的世界里，學(xué)習(xí)發(fā)生在SDN控制器里(有人稱之為centralized mac learning)，因?yàn)榭刂破饕欢ㄒ浪芾淼倪@個(gè)網(wǎng)絡(luò)究竟連接了一些什么mac/IP，才能proactive的編輯整個(gè)SDN網(wǎng)絡(luò)的流表。一種比較常見(jiàn)的方式是：交換機(jī)把ARP request/reply以packet-in的形式發(fā)給控制器，控制器便學(xué)習(xí)到了mac, vlan, IP, 交換機(jī)和端口之間的關(guān)系。在開(kāi)源的floodlight里有一個(gè)類似的例子，在所有其他開(kāi)源的控制器里，也都有類似的例子。

講到這里，做OpenStack/CloudStack的兄弟們會(huì)仰天大笑：太老土了吧，還centralized mac learning?有了orchestration之后，網(wǎng)絡(luò)中所有vm的一切信息在第一時(shí)間已經(jīng)被控制器知道了!此言不假，但有兩個(gè)問(wèn)題：第一，如果有人沒(méi)有部署orchestration而只用物理服務(wù)器怎么辦?其實(shí)，對(duì)于SDN網(wǎng)絡(luò)而言，orchestration也是某種意義上的mac learning，只不過(guò)這個(gè)learnning沒(méi)有通過(guò)ARP。

第二個(gè)問(wèn)題則更加重要，無(wú)論SDN控制器用何種方式學(xué)到mac/IP在網(wǎng)絡(luò)中的位置，這僅僅是第一步，接下來(lái)的問(wèn)題是：怎樣回復(fù)服務(wù)器發(fā)出的ARP request? 這個(gè)問(wèn)題是SDN系統(tǒng)設(shè)計(jì)的一個(gè)挑戰(zhàn)，并且這個(gè)挑戰(zhàn)會(huì)隨著系統(tǒng)feature的不斷豐富，一次又一次的出現(xiàn)。接下來(lái)博主主要會(huì)從L2和L3兩個(gè)方面分析一下這個(gè)問(wèn)題可能的解法，歡迎大家查漏補(bǔ)缺。

如果source和destination處于一個(gè)subnet，這是一個(gè)純二層的問(wèn)題。有兩種極端的解法。

極端解法一：讓SDN控制器回復(fù)所有的ARP request。既然SDN控制器已經(jīng)通過(guò)orchestration或者ARP packet-in的方式學(xué)習(xí)到了網(wǎng)絡(luò)中的mac，那么只要將所有ARP request都以packet-in的形式發(fā)送到控制器，控制器就完全有能力將ARP reply通過(guò)packet-out的方式回復(fù)給source。

這種極端做法顯而易見(jiàn)的缺點(diǎn)是：過(guò)多的ARP request會(huì)讓SDN控制器應(yīng)接不暇，成為潛在的安全隱患。于是，不少SDN廠家在這種方案的基礎(chǔ)上進(jìn)行了改進(jìn)，一種改進(jìn)的思路是：既然控制器上有一個(gè)大表記錄著網(wǎng)絡(luò)中所有IP到mac的映射，那么我們就可以在所有網(wǎng)絡(luò)邊緣交換機(jī)上把這個(gè)表cache下來(lái)，這樣，當(dāng)交換機(jī)再次收到ARP request的時(shí)候，就可以通過(guò)查找這個(gè)表直接回復(fù)相應(yīng)的ARP reply，而不需要廣播。

以上這個(gè)改進(jìn)確實(shí)是個(gè)可行的方案，但是有兩個(gè)前提：1)用戶不在乎高可靠性(high availability)，2)一定要部署在有orchestration的環(huán)境當(dāng)中。但這兩個(gè)大大的前提往往會(huì)讓相當(dāng)一部分客戶止步。首先如果source和destination都好好的，但是SDN控制器宕了，于是最基本的ARP便無(wú)法正常工作，這是一件讓任何客戶都很難接受的事情。其次，在沒(méi)有orchestration的環(huán)境當(dāng)中，有些服務(wù)器是不主動(dòng)說(shuō)話的(silent server)，也就是說(shuō)在silent server發(fā)出第一個(gè)ARP之前，控制器根本沒(méi)有機(jī)會(huì)得知它的存在。在這種情況下，SDN網(wǎng)絡(luò)必須要能夠正確的廣播ARP request，當(dāng)SDN網(wǎng)絡(luò)收到silent server的ARP reply之后，還要能夠正確的將其轉(zhuǎn)發(fā)。

極端解法二：在一個(gè)廣播域中廣播ARP request。既然極端解法一并不適用于所有的情形，那么我們便很自然的想到了另外一個(gè)極端解法，索性廣播ARP request吧，該誰(shuí)回復(fù)ARP reply就讓誰(shuí)回復(fù)。這樣做有幾個(gè)好處，首先是SDN網(wǎng)絡(luò)中ARP的行為和傳統(tǒng)二層交換中ARP的行為是一致的?？蛻粼赿estination打開(kāi)tcpdump會(huì)看到ARP request。而在之前的方案中，destination是看不到ARP request的。單就這一點(diǎn)，在向客戶解釋說(shuō)明的時(shí)候就省了好多事。第二個(gè)好處是即便控制器宕了，只要source和destination還在，ARP就能工作。第三個(gè)好處是這個(gè)方案解決了silent server的問(wèn)題，只要廣播處理的正確，silent server就能夠收到ARP request并回復(fù)ARP reply。

當(dāng)然這個(gè)方案的代價(jià)也很大，就是要正確的處理廣播。如果僅僅是二層網(wǎng)絡(luò)，我們可以用spanning tree，用SDN控制器計(jì)算spanning tree是一件麻煩但能夠做到的事情。如果是二層被三層隔離，就需要打隧道了。以vxlan為例，最初vxlan要求在underlay網(wǎng)絡(luò)中部署IP multicast來(lái)處理ARP，沒(méi)有人愿意，于是才有了后來(lái)的unicast-only vxlan。

博主把極端解法二稱為“種樹(shù)”：從本質(zhì)上來(lái)講，SDN控制器其實(shí)在為每一個(gè)廣播域種一棵沒(méi)有環(huán)的樹(shù)，好讓ARP在這棵樹(shù)上廣播。如何高效的“種樹(shù)”是真正體現(xiàn)各個(gè)廠家硬實(shí)力的地方，不管是用spanning tree在二層種樹(shù)，打隧道在三層種樹(shù)還是其他方法，這棵樹(shù)都必須要做到：無(wú)論任何網(wǎng)絡(luò)拓?fù)浠蛘呷魏尉W(wǎng)絡(luò)事件，有且只有一個(gè)廣播報(bào)文到達(dá)廣播域中的各個(gè)服務(wù)器。

分析到這里，博主已經(jīng)把當(dāng)source和destination在一個(gè)subnet時(shí)，處理ARP的種種考慮走馬觀花的討論了一遍。博主才疏學(xué)淺，但在博主知識(shí)范圍內(nèi)的ARP解決方案基本就是在以上兩個(gè)極端之間找一個(gè)折中并做一定的創(chuàng)新。

討論完source和destination處于同一個(gè)subnet的情況，我們來(lái)看一下兩者處于不同subnet的情況，這時(shí)我們需要考慮兩個(gè)問(wèn)題。

問(wèn)題一：誰(shuí)是default gateway?

傳統(tǒng)網(wǎng)絡(luò)中，二層三層的界限往往非常清晰，二三層分界的地方就是default gateway所在的地方。但在seamless vm migration大行其道的今天，二層三層的界限越來(lái)越模糊，我們已經(jīng)很難明確的指出default gateway在網(wǎng)絡(luò)當(dāng)中的位置了，于是常聽(tīng)人們感嘆：default gateway is everywhere。博主見(jiàn)識(shí)有限，到目前為止見(jiàn)到的default gateway大體上會(huì)出現(xiàn)在三個(gè)地方。

第一種情形是網(wǎng)絡(luò)中有一個(gè)專門的router(可能是硬件也可能是OVS)來(lái)做default gateway，這種情形常出現(xiàn)在overlay的解決方案中，比如Juno release之前的neutron reference implementation，比如vxlan L3 gateway。有客戶擔(dān)心這種方案的高可靠性，于是人們又在這種方案之上加入了VRRP。

第二種情形是default gateway在SDN控制器上。有些開(kāi)源的SDN控制器就在采用這種方式。一種常見(jiàn)的邏輯是這樣的：source發(fā)出了ARP request問(wèn)default gateway的mac，交換機(jī)把這個(gè)ARP request以packet-in的形式告訴控制器，控制器再以packet-out的形式把ARP reply發(fā)給source，于是source就知道了default gateway的mac。我知道有兄弟會(huì)說(shuō)：這樣控制器不又成了單點(diǎn)故障和bottleneck了嗎?所以人們?cè)诖嘶A(chǔ)之上進(jìn)行了改進(jìn)，發(fā)明了第三種部署default gateway的方式。

這第三種方式就是把default gateway部署在所有的網(wǎng)絡(luò)邊緣的交換機(jī)上，有人稱之為destributed default gateway。在情形二中，SDN控制器已經(jīng)掌握了所有subnet的default gateway，我們完全可以把這個(gè)信息以某種方式cache/offload到所有的網(wǎng)絡(luò)邊緣的交換機(jī)上。這樣，這些交換機(jī)就可以代替控制器回復(fù)所有要default gateway mac的ARP request。

在以上三種方案中，方案一目前來(lái)說(shuō)最常見(jiàn)。方案三在被越來(lái)越多的人接受，因?yàn)樗膬?yōu)勢(shì)實(shí)在太明顯了。

問(wèn)題二：如何處理silent server?

如果沒(méi)有部署任何的orchestration system，如果網(wǎng)絡(luò)中還有大量的bare metal server，那么silent server帶來(lái)的問(wèn)題就不容忽視。我們?cè)O(shè)想一下下面這個(gè)場(chǎng)景：source和destination處在不同的subnet，并且destination是一個(gè)silent server。如果source向destination發(fā)了一個(gè)ping echo request，由于SDN控制器對(duì)destination一無(wú)所知，所以網(wǎng)絡(luò)中不會(huì)有關(guān)于destination的任何表項(xiàng)，于是這個(gè)echo request被很自然的packet-in到了控制器，此時(shí)的控制器又能對(duì)這個(gè)packet-in做什么呢?

博主目前還沒(méi)有看到任何關(guān)于這個(gè)問(wèn)題的公開(kāi)討論。一個(gè)最魯莽的辦法就是控制器以packet-out的方式在SDN網(wǎng)絡(luò)邊緣的所有端口上發(fā)ARP request，要destination IP所對(duì)應(yīng)的mac。如果destination真的接入了我們的網(wǎng)絡(luò)，便會(huì)回復(fù)ARP reply，那時(shí)控制器便會(huì)學(xué)習(xí)到destination連接在哪臺(tái)交換機(jī)的哪個(gè)端口，相應(yīng)的表項(xiàng)便會(huì)得到更新。只是這樣一個(gè)魯莽的方法代價(jià)太大了。如果哪位兄弟有更好的辦法，歡迎提出來(lái)大家一起討論。

講到這里，博主已經(jīng)把SDN系統(tǒng)設(shè)計(jì)中關(guān)于ARP的考量梳理了一遍。不過(guò)ARP不會(huì)就此罷休。在以后的文章中，博主還會(huì)討論到NAT和floating IP，到那時(shí)，ARP會(huì)卷土重來(lái)，給我們制造更多的麻煩。