VXLAN在數據中心大量VM互聯場景下，能否免去flood-learn學習？
VXLAN一般都是使用flood-learn模式進行地址學習，目的是為了學習VTEP和MAC的對應關係，但是實際上在現有的環境中(數據中心大量VM互聯)，vm的mac地址都是有hypervisor生成的，也就是說每個MAC在那個HOST，對應到那個VTEP上，這個關係應該是已知，或者可以推算出來的，那麼能否直接通過這個關係通過controller下發流表，節省掉flood-learn的學習過程呢？
--------------------------------------------------------------------------------------------------------------參考阿里雲的vpc的技術分享，貌似阿里就是用的上述方案。網路虛擬化技術-技術實現-江鶴-在線播放-優酷網，視頻高清在線觀看25：27秒的嘉賓提問提到了類似的問題。
謝邀。
同學們可能知道大二層技術，可能不知道大二層有哪些好處？
安全
比如一組伺服器，具有相同的安全屬性，它們之間可以互相訪問，那可以將它們放在一個相同的網段，為何？安全邊界一般設置在不同網段之間，比如有兩個網段，10.1.1.0/24 屬於伺服器，10.1.2.0/24 屬於客戶端，那麼就可以在防火牆上對這兩個網段進行控制，允許或拒絕，伺服器在一個網段、一個安全區域，非常便利安全策略的應用，如果把一些伺服器放在10.1.3.0/24、10.1.4.0/24、…10.1.N.0/24，做安全策略的隔離，配置工作量大大上升。
便利
一個主機只要處在一個大二層網路，不管身在何處，不管在哪個數據中心，它的IP可以保持不變，和主機IP相關的都無需重新配置，既然IP不變，主機的現有的通信會話都可以保持不斷。而如果不在一個二層網路，則意味著主機要重新配置新的IP，另一個網段的IP，則安全策略全部需要重新配置，現有的會話肯定會斷開。高效
大二層網路主機之間的通信，無需網關等三層設備介入，只需ARP廣播發現對方的MAC地址，可以之間通信，對於用戶來說，所有主機彷彿連接在一個二層交換機上，直接通信，而無需三層路由。接下來回答題主的問題
首先你提到的VxLAN的「Flood-Learn」模式，即流量驅動模型，先有ARP等廣播流量，然後VTEP學習到「源MAC、源IP」，記錄到「MAC、IP、VTEP」表相中，依據這些表相來轉發後續的單播流量。這是VxLAN早期技術了，沒有控制協議來分發這三者的對應關係，完全靠窺探流量來被動學習。
現在MP-BGP被選作這個控制協議，使用EVPN「Address-Family」在VTEP之間，分享彼此二層網路中主機的「MAC、IP」，這個用MP-BGP就可以完成分享，這種是控制協議模型。
那VTEP怎麼知道自己二層網路里主機的MAC、IP的呢？依然使用傳統的辦法，即流量驅動模型，VTEP依靠學習主機的ARP廣播、回應，或「Unknown MAC」單播包的泛洪來學習的，這個依然如此。
換句話說，VTEP之間使用控制協議模型，而VTEP與主機之間依然使用流量驅動模型！
為何Controller不靜態下發主機「IP、MAC」給各VTEP？
最大的原因是靈活，試想如果一個虛擬主機，從一個VTEP1後遷移到另一個VTEP2後，如何更新這個對應關係，而有了MP-BGP，VTEP2會動態通告這個主機的「MAC、IP」，這一切都是自動發生的，而無需用戶手動配置！謝邀！你問的實際上是vxlan的控制平面如何做的問題，
我簡單點，分為兩種情況，
一，不需要SDN Controller實現VxlanVxlan有三種控制平面實現方式：Multicast, Unicast, MP-BGP EVPN
a. Multicast做控制平面- 數據中心每台交換機上需要配置VTEP，保證VNI加入到相同的組播組中
- 組播必須支持Any-Source Multicast (ASM)
- RFC 7384
b.Unicast做控制平面
- 這個沒什麼好說的，靜態配置，指定VETP路徑
c.MP-BGP EVPN作為控制平面
- draft-ietf-bess-evpn-overlay-07
- 不再採用泛洪學習的方式
- 解決了Multi-homing的問題
- 解決了MAC-Mobility的問題
- 解決了Vxlan L2/L3 Gateway的問題
二，有SDN Controller
有SDN Controller的也可以用上面的方式，既然有SDN Controller了，自然也有更高級的方式a. XMPP or OVS-DB
- 與MP-BGP有些類似，Controller通過XMPP或者OVS-DB直接交換路由信息
當然可以了，對SDN來說，，除了廣播學習以外，另兩種典型的策略分別是首包上傳和預推送，首包上傳是通過flow miss（也就是未匹配到流表）時上傳控制器，由控制器查找相應信息並下發流表；預推送是指創建vm時立即推送所有可能需要的流表到交換機。前一種優點在於流表數量可以控制在比較少的量級，但是控制器壓力較大，一旦控制器故障會導致嚴重網路故障；後一種要穩定得多，但是需要推送的流表數量可能較多。EVPN的方案並不看好，最多能算個補充性的技術。
openstack里的arp responder和l2 population就是這樣的實現，而我參與及調研過的開源網路虛擬化如果基於layer2的話也大多類似。
上面兄弟回復的evpn是比較新穎的解決方案，我個人很喜歡bgp的擴展性，但目前看主要是廠商驅動的比較多，從sdn的角度看，引入bgp在網路虛擬化這個領域可能比較重，而且相關的協議有些還處於draft階段，有實力的廠商比如阿里，ucloud目前都應該尚未採用evpn。
推薦閱讀：