拋磚引玉 下一代數據中心的虛擬接入技術VN-Tag和VEPA
數據中心的虛擬接入是新一代數據中心的重點課題，各方已經爭奪的如火如荼。目前網絡上的中文資料還不多，根據自己的經驗寫了一點對虛擬接入的理解，意在丟磚，引出真正的大佬。
一、為什么虛擬化數據中心需要一臺新的交換機
隨著虛擬化技術的成熟和x86 CPU性能的發展，越來越多的數據中心開始向虛擬化轉型。虛擬化架構能夠在以下幾方面對傳統數據中心進行優化：
◇ 提高物理服務器CPU利用率；
◇ 提高數據中心能耗效率；
◇ 提高數據中心高可用性；
◇ 加快業務的部署速度
正是由于這些不可替代的優點，虛擬化技術正成為數據中心未來發展的方向。然而一個問題的解決，往往伴隨著另一些問題的誕生，數據網絡便是其中之一。隨著越來越多的服務器被改造成虛擬化平臺，數據中心內部的物理網口越來越少，以往十臺數據庫系統就需要十個以太網口，而現在，這十個系統可能是駐留在一臺物理服務器內的十個虛擬機，共享一條上聯網線。
這種模式顯然是不合適的，多個虛擬機收發的數據全部擠在一個出口上，單個操作系統和網絡端口之間不再是一一對應的關系，從網管人員的角度來說，原來針對端口的策略都無法部署，增加了管理的復雜程度。
其次，目前的主流虛擬平臺上，都沒有獨立網管界面，一旦出現問題網管人員與服務器維護人員又要陷入無止盡的扯皮中。當初虛擬化技術推行的一大障礙就是責任界定不清晰，現在這個問題再次阻礙了虛擬化的進一步普及。
接入層的概念不再僅僅針對物理端口，而是延伸到服務器內部，為不同虛擬機之間的流量交換提供服務，將虛擬機同網絡端口重新關聯起來。
#p#
二、僅僅在服務器內部實現簡單交換是不能的
既然虛擬機需要完整的數據網絡服務，為什么在軟件里不加上呢？
沒錯，很多人已經為此做了很多工作。作為X86平臺虛擬化的領導廠商，VMWare早已經在其vsphere平臺內置了虛擬交換機vswitch，甚至更進一步，實現了分布式虛擬交互機VDS（vnetwork distributed switch），為一個數據中心內提供一個統一的網絡接入平臺，當虛擬機發生vmotion時，所有端口上的策略都將隨著虛擬機移動。
VMWare干得貌似不錯，實際上在當下大多數情況下也能夠滿足要求了。但如果談到大規模數據中心精細化管理，內置在虛擬化平臺上的軟件交換機還有很多問題沒有解決。首先，目前的vswitch至多只是一個簡單的二層交換機，沒有QoS、沒有二層安全策略、沒有流量鏡像，不是說VMWare沒有能力實現這些功能，但一直以來這些功能好像都被忽略了；其次，網管人員仍然沒有獨立的管理介面，同一臺物理服務器上不同虛機的流量在離開服務器網卡后仍然混雜在一起，對于上聯交換機來說，多個虛擬機的流量仍然共存在一個端口上。
虛擬平臺上的軟件交換機雖然能夠提供基本的二層服務，但是由于這個交換機的管理范圍被限制在物理服務器網卡之下，它沒法在整個數據中心提供針對虛擬機的端到端服務，只有一個整合了虛擬化軟件、物理服務器網卡和上聯交換機的解決方案才能徹底解決所有的問題。
這個方案涉及范圍如此之廣，決定這又是一個只有業界大佬才能參與的游戲。
#p#
三、誰在開發新型交換機？
HP，Cisco。
一個是PC服務器王者，近年開始在網絡領域攻城略地，勢頭異常兇猛；一個是網絡大佬，借著虛擬化浪潮推出服務器產品，頑強地擠進這片紅海。
針對前文所說的問題，兩家拋出了各自的解決方案，目的都是重整虛擬服務器同數據網絡之間那條薄弱的管道，將以往交換機上強大的功能延伸進虛擬化的世界，從而掌握下一代數據中心網絡的話語權。
Cisco和VN-TAG
虛擬化平臺軟件如VMWare ESX部署之后，會模擬出一整套硬件資源，包括CPU、硬盤、顯卡，以及網卡，虛擬機運行在物理服務器的內存中，通過這個模擬網卡對外交換數據，實際上這個網卡并不存在，我們將其定義為一個虛擬網絡接口VIF（Virtual Interface）。VN-tag是由Cisco和VMWare共同提出的一項標準，其核心思想是在標準以太網幀中增加一段專用的標記—VN-Tag，用以區分不同的VIF，從而識別特定虛擬機的流量。
VN-Tag添加在目的和源MAC地址之后，在這個標簽中定義了一種新的地址類型，用以表示一個虛擬機的VIF，每個虛擬機的VIF是唯一的。一個以太幀的VN-Tag中包含一對這樣新地址dvif_id和svif_id，用以表示這個幀從何而來，到何處去。當數據幀從虛擬機流出后，就被加上一個VN-Tag標簽，當多個虛擬機共用一條物理上聯鏈路的時候，基于VN-Tag的源地址dvif_id就能區分不同的流量，形成對應的虛擬通道，類似傳統網絡中在一條Trunk鏈路中承載多條VLAN。只要物理服務器的上聯交換機能夠識別VN-Tag，就能夠在交換機中直接看到不同的VIF，這一下就把對虛擬機網絡管理的范圍從服務器內部轉移到上聯網絡設備上。
思科針對VN-Tag推出了名為Palo的虛擬服務器網卡，Palo卡為不同的虛擬機分配并打上VN-Tag標簽，上聯交換機與服務器之間雖然只有一條網線，但通過VN-Tag上聯交換機能區分不同虛擬機產生的流量，并在物理交換機上生成對應的虛擬接口VEth，和虛擬機的VIF一一對應，好像把虛擬機的VIF和物理交換機的VEth直接對接起來，全部交換工作都在上聯交換機上進行，即使是同一個物理服務器內部的不同虛擬機之間的流量交換，也通過上聯交換機轉發。這樣的做法雖然增加了網卡I/O，但通過VN-Tag，將網絡的工作重新交回到網絡設備。而且，考慮到萬兆接入的普及，服務器的對外網絡帶寬不再是瓶頸，此外，利用Cisco Nexus 2000這種遠端板卡設備，網管人員還能夠直接在一個界面中管理數百臺虛擬機，每個虛擬機就好象在傳統的接入環境中一樣，直接連接到一個交換機網絡端口。
目前，思科推出的UCS服務器已經能夠支持VN-tag，當Palo卡正確安裝之后，會對上層操作系統虛擬出多個虛擬通道，每個通道對應一個VIF，在VMWare EXS/ESXi軟件中可以將虛擬機繞過vswitch，直接連接到這些通道上，而在UCS管理界面上則能夠看到對應的虛擬機，使網管人員能夠直接對這些端口進行操作。
Cisco同VMWare已經將向IEEE提出基于VN-Tag的802.1Qbh草案，作為下一代數據中心虛擬接入的基礎。
HP和VEPA
Cisco提出的VN-Tag，在IT業界引起的震動遠遠大于在客戶那得到的關注，如果802.1Qbh成為唯一的標準，Cisco等于再一次制定了游戲規則，那些剛剛在交換機市場上屯下重兵的廠商，在未來數據中心市場上將追趕得異常痛苦。此外，VN-Tag是交換機加網卡的一攬子方案，還能夠幫助Cisco快速切入服務器市場，對其他人來說是要多不爽有多不爽。
很容易猜到，這其中最不爽的就是HP，在交換機和服務器領域跟Cisco明刀明槍地干上之后，被這樣擺上一道，換誰也不可能無動于衷。HP的應對很直接，推出一個類似的方案，替代VN-Tag。
HP的辦法稱為VEPA（Virtual Ethernet Port Aggregator），其目的是在部署了虛擬化環境的服務器上實現同VN-tag類似的效果，但VEPA采取了一條截然不同的思路來搭建整個方案。
簡單來說，VEPA的核心機制就是兩條：修改生成樹協議、重用Q-in-Q。
VEPA的目標也是要將虛擬機之間的交換行為從服務器內部移出到上聯交換機上，當兩個處于同一服務器內的虛擬機要交換數據時，從虛擬機A出來的數據幀首先會經過服務器網卡送往上聯交換機，上聯交換機通過查看幀頭中帶的MAC地址（虛擬機MAC地址）發現目的主機在同一臺物理服務器中，因此又將這個幀送回原服務器，完成尋址轉發。整個數據流好象一個發卡一樣在上聯交換機上繞了一圈，因此這個行為又稱作“發卡彎”。
雖然“發卡彎”實現了對虛擬機的數據轉發，但這個行為違反了生成樹協議的一項重要原則，即數據幀不能發往收到這個幀的端口，而目前虛擬接入環境基本是一個大二層，因此，在接入層，不可能使用路由來實現這個功能，這就造成了VEPA的機制與生成樹協議之間的矛盾。
但是VEPA沒有vPC，在接入層還是要跑生成樹。HP的辦法就是重寫生成樹協議，或者說在下聯端口上強制進行反射數據幀的行為（Reflective Relay）。這個方式看似粗暴，但一勞永逸地解決了生成樹協議和VEPA機制的沖突，只要考慮周全，不失為一步妙棋。
除了將虛擬機的數據交換轉移到物理服務器上之外，VN-Tag還做了一項重要的工作，就是通過dvif_id和svif_id這對新定義的地址對不同虛機流量進行區分。HP在這里的搞法同樣簡單直接，VEPA使用Q-in-Q在基本的802.1q標記外增加了一層表示不同虛擬機的定義，這樣在VLAN之外，VEPA還能夠通過Q-in-Q區分不同的虛擬機，只要服務器網卡能夠給數據幀打上Q-in-Q標記，上聯交換機能夠處理Q-in-Q幀，基本就可以將不同的虛擬機流量區分開來，并進行處理。
至此，VEPA看起來已近能夠實現同VN-Tag類似的功能，因此HP也將VEPA形成草案，作為802.1Qbg的基礎提交至IEEE。不得不說，VEPA是個非常聰明的設計，不管是對生成樹行為的修改，還是利用Q-in-Q都不是什么不得了的創新，目前的交換機廠商只要把軟件稍微改改，就能夠快速推出支持802.1Qbg的產品，重新搭上數據中心這班快車，追上之前被Cisco甩下的距離。
VN-Tag和VEPA
自從Cisco祭出VN-Tag大旗后，各種爭議就沒停過，直到HP推出VEPA，這場口水仗達到高潮，隨著2011年，802.1Qbh和802.1Qbg標準化進程的加快，圍繞虛擬接入下一代標準的爭奪將進入一個新的階段。
這也不難理解，隨著數據中心內虛擬機數量的不斷增加，越來越多的物理網口轉化為虛擬的VIF，如果一家網絡廠商沒法提供相應的接入解決方案，它的餅會越來越小，活得非常難受。
VN-Tag就是Cisco試圖一統下一個十年數據中心的努力，HP雖然同思科正面開戰時間不長，但從VEPA來看，其手法相當老辣。由于VEPA沒有對以太網數據結構提出任何修改，實現成本非常低，以往被思科掃到大門之外的廠商，一下子見到了曙光，前仆后繼地投靠過來，Juniper、IBM、Qlogic、Brocade等等都毫不掩飾對VEPA的期待，Extreme甚至表示，已近著手修改OS以保證對VEPA的支持。待各方站隊結束，大家發現Cisco雖然有強大的盟友VMWare，但另外一邊幾乎集結了當今網絡界的所有主流廠商，輿論也逐漸重視VEPA的優點，甚至Cisco自己也不得不松嘴說會考慮對802.1Qbg的支持。
戲演到這里，很多人幸災樂禍地等著看Cisco怎么低頭。但有一個問題，VEPA這么完美，為啥Cisco之前沒有采用類似的思路？僅僅為構建一個封閉的體系架構嗎？我認為不是。
回答這個問題前，我們首先要弄清楚另一個問題。以VMWare ESX/ESXi為例，由于ESX/ESXi自帶的vswitch只是模擬了一臺二層交換機，當一臺物理服務器上兩個處于不同VLAN的虛擬機之間需要交換數據時，vswitch是無能為力的。只能將數據送到上聯物理交換機上，由物理交換機完成VLAN間的三層轉發。聽起來是不是很熟悉？這和之前提到的VN-Tag與VEPA的機制很相似，如果現有的虛擬化環境已經能夠將數據交換的行為轉移到上聯交換機，為啥還要大費周折地提出一個新標準呢？
這是因為，當下的這種方案是利用VLAN來隔離不同虛擬機，通過TRUNK將對應多個虛擬機的VLAN送到物理交換機上。這種方式打破了數據中心內對VLAN的使用慣例，比如，網管人員通常會把負責同一業務的多臺服務器放在一個VLAN內，如果VLAN標簽都被用來隔離虛擬機了，則沒法按照傳統方式來區分不同業務，解決了一個問題，帶來另外的問題，這是絕對行不通的。
現在，我們可以回答之前的問題了，新一代的虛擬接入方案是要在不影響802.1Q等原有網絡行為的前提下，完成對虛擬機的接入、區分和管理。有人會說，用PVLAN不可以嗎?但我們怎么保證PVLAN沒有其他的用處呢？出于這樣的思路，Cisco沒有利用現有的任何技術，提出了一個全新的實現方案，正因為VN-Tag從出生起就“干干凈凈”，同誰都沒有瓜葛，因此VN-Tag攜帶的信息就能夠在整個數據中心內自由的傳遞，從而快速為用戶搭建起一個清晰、完整的虛擬接入平臺，所謂“磨刀不誤砍柴工”。
HP充分利用了現有條件，VEPA的整個架構看上去簡潔、高效，但是對生成樹協議改動和利用Q-in-Q無疑會影響到現網的行為。生成樹協議的效率和問題一直是個老大難，但無數聰明絕頂的高手琢磨了這么多年，協議的變動仍然不大，說明對這種基本協議的修改不是一蹴而就的，往往遷一發而動全局，現有的模式是各方協調、妥協的結果。VEPA要在短時間內拿出一個完美的方案，所需花費的精力也許并不比重新提一套方案少。
除了協議本身之外，擺在HP和VEPA面前還有兩個難題，首當其沖就是VMWare的支持。VEPA雖然對交換機硬件改動不大，但要真正跑起來，還需要虛擬化平臺軟件的支持，虛擬網卡和虛擬交換機得主動把所有數據幀扔到上聯交換機上，后面的故事才能續上。可是VMWare還是Cisco在VN-Tag上最大的盟友，雖然Cisco已經表示會支持802.1Qbg，但會有多及時就難說了。
時間也就是VEPA的第二個困難。目前，思科的UCS服務器已經能夠提供端到端的VN-Tag部署。而HP的Virtual Connect解決方案僅實現了Q-in-Q的多鏈路，對“發夾彎”的支持并不好，也沒有VMWare的支持，說白了，VEPA還只是圖紙上的設計，沒有實際產品支撐。此外，虛擬接入只是下一代數據中心組成之一，FCoE、THRILL等都非常重要，針對這些技術，HP仍拿不出成型的產品，相反，Cisco在所有領域幾乎都布局完畢，留給HP的時間不多了。
這場針對數據中心接入的爭奪，在2011年必將愈演愈烈，Cisco攜全線產品勢在必得，而HP的VEPA評價聰明的設計，得到業界廣泛支持，故事結局如何，還待靜觀其變。
#p#
彎曲評論
雁過留聲——“下一代數據中心的虛擬接入技術–VN-Tag和VEPA”有59個回復
1、tang ling 于 2011-01-16 5:15 下午 深入淺出，說得很清楚，佩服佩服
2、deltali 于 2011-01-16 5:52 下午 寫的不錯，有理有據的。要是能把寫這篇文章的參考資料也給出鏈接就更好了
3、冬瓜頭 于 2011-01-16 5:55 下午 想請教一下樓主，Multihop FCoE，FCoE forwarder，Fabric Extender，這些詞我前陣子搜索過，一直沒有找到細節的東西，不知道樓主是否了解，請指教！
4、福尼 于 2011-01-16 7:21 下午 非常好的觀點，非常清晰的思路
5、ZC 于 2011-01-16 7:49 下午 好文，學習。
新平臺/新標準的搭建不論對誰都是事關生死 的大事，就看業界怎么演繹了，呵呵。
6、gaohl 于 2011-01-16 8:57 下午 寫的非常好，學習了
7、kernelchina 于 2011-01-16 9:49 下午 按道理，虛擬機之間的流量在vSphere內部應該更快點，為什么要跑到外面的交換機上轉一圈再回來？如果把vswitch做成一個full feature的switch，會不會更好一點？
physical switch vswitch–virtual machine.
8、冬瓜頭 于 2011-01-16 10:00 下午 不懂網絡內核方面，猜測如果做入那些full feature，esx上的cpu恐怕吃不消了吧。
9、deltali 于 2011-01-16 10:03 下午 to kernelchina:
看這篇文章的意思，就是要把虛擬機當真實的機器用，讓它們之間的流量也暴露在整個網絡中，就像2臺物理主機共用一根網線一樣。
10、陳懷臨 于 2011-01-16 10:10 下午 這篇文章意義重大。。。。。。
#p#
11、冬瓜頭 于 2011-01-16 10:15 下午 http://bradhedlund.com/2010/09/15/vmware-10ge-qos-designs-cisco-ucs-nexus/
這人是思科的，他的博客偷了不少這方面的料。
12、Panabit 于 2011-01-16 10:22 下午 這個文章好，拜讀了！
13、旁觀者清 于 2011-01-16 10:29 下午 這都是過分渲染“云”計算，虛擬化的結果。
VN-tag和VEPA是虛擬接入的兩個標準草案，其本質從用戶的角度來看，不過是虛擬機識別和管理的技術實現手段而已。
思科推行VN-tag的市場目的就是搞壟斷，就像當年的EIGRP一樣；其他廠商推行VEPA就是不想這塊細分市場被思科所壟斷，就行OSPF一樣。 這種從網絡設備到服務器/網卡的端到端壟斷是思科所追求的，也正是其他廠商不希望看到的。
14、picktracy 于 2011-01-16 10:30 下午 功力啊功力，清晰易懂，好文。
15、冬瓜頭 于 2011-01-16 11:34 下午 和FCoE一樣。還好有個iSCSI頂著。。
16、kernelchina 于 2011-01-17 12:38 上午 以前看cisco的nexus 1000v和vn-link沒搞明白是什么意思，現在有點明白了。把虛擬機當真實的機器用，需要各方面加倍，然后再分割，否則性能沒法保證。
17、cong 于 2011-01-17 1:14 上午 好文！
PS：冬瓜頭同學也寫一個吧
18、冬瓜頭 于 2011-01-17 3:38 上午 To cong:
呵呵，感謝這位的 鞭策，此文甚好，學習中，后續文章會努力提高質量！謝謝！
19、libing 于 2011-01-17 4:36 上午 to 冬瓜頭
FCoE forword和fiber channel forward一般指的都是服務器上聯的交換機，FCoE的鏈路目前只能實現一跳，存在于服務器網卡和forward之間，FCoE的幀在forward上被拆開，并通過FC鏈路送到SAN上。
而要將FCoE鏈路延長到更遠的交換機，就是Multihop FCoE，即FCoE的多跳。Multihop FCoE在FC-BB-5中已經有了對應標準，實現方式也不止一種。
Fabric Extender一般指Cisco的Nexus 2000擴展設備，相當于把機架式交換機的板卡取出來，作為一個獨立設備。這樣的好處是可以以ToR的方式不限，以EoR的管理。
deltali的意見很好，我找了一個FEX的說明：
http://www.networkworld.com/community/node/39236
20、libing 于 2011-01-17 4:38 上午 to kernelchina
基本上，虛擬接入解決的不是性能問題，而是管理問題，將網絡的行為重新還給網絡設備。
當然，解決一個問題的方式有很多中，這只是其中一種
#p#
21、xie 于 2011-01-17 7:04 上午 不知道CISCO針對TRILL是什么解決方案
22、tom 于 2011-01-17 5:50 下午 好文，必須要頂
23、tom 于 2011-01-17 5:59 下午 猜測一下結果，VEPA將會贏得勝利，一個封閉的系統沒有前途，就如EIGRP一樣。。。。。。
24、cius 于 2011-01-17 6:46 下午 to 旁觀者清
實際上你說的OSPF是Cisco除了BGP外貢獻最大的標準協議之一。從對RFC的貢獻看，Cisco從來不想做一個“壟斷的協議”（這和當年IBM、DEC和HP有多么大的不同啊），Cisco只是想搶先推出一些標準，并試圖放到IEEE和IETF上公開，不過想在這些領域搶得先機而已。若說壟斷，憑著現在全球市場占有率，直接出私有協議不就完了，象水果公司的OS那樣。
25、cius 于 2011-01-17 6:49 下午 to libing
Palo繞過Hypervisor實現VM直接驅動的I/O，這可是大大的性能問題，想想現在那些I/O密級型的應用
26、cius 于 2011-01-17 6:49 下午 to libing
Palo繞過Hypervisor實現VM直接驅動的I/O，這可是大大的性能改善（Hypervisor Bypass），想想現在那些I/O密級型的應用
27、cius 于 2011-01-17 6:54 下午 to tom
現在很難說，和EIGRP最大的不同是，Cisco當年不同意公布EIGRP協議，而802.1Qbh從一開始就是開放的。而且Cisco進可攻、退可守：進，可以推行干干凈凈的虛擬化接入方案802.1Qbh，不增加用戶部署的管理負擔（Spanning Tree快在數據中心死了）；退，可以非常容易支持Qbg，和大家一樣不就完了
28、tang ling 于 2011-01-17 7:29 下午 to Cius,
關于繞過虛擬Hypervisor，直接讀取I/O的技術意義，對VN-LINK等技術有重要的間接推動作用. 畢竟， “Palo卡的vNIC技術，配合VN-Link以及VMWare的Hypervisor Bypass技術，可以讓網卡流量不經過CPU和Hypervisor，完全交由Palo網卡直接硬件處理。這樣能帶來帶寬吞吐30%的性能提升”。
http://www.cisco.com/en/US/solutions/collateral/ns340/ns517/ns224/ns944/white_paper_c11-593280_ps10279_Products_White_Paper.html
但是，從實際看，包括同虛擬化廠商的溝通，坦率說，現在還沒有killer級應用，必須用direct I/O；就客戶而言，國內也極少有實際部署direct I/O案例。我了解只有個別類似于涉及視頻編輯的應用，可能會考慮。
因此，如果你這邊有關于Direct I/O在實際中的應用情況，可否分享一下~
29、deltali 于 2011-01-17 7:48 下午 采用Direct I/O的話，首先會對live migration造成影響。這個是絕對不能接受的，不知道現在這方面的問題解決的如何了？
其次跟嵌入式設備不同，在服務器虛擬化這邊，還是要盡量避免讓虛擬機直接控制硬件。
30、Da Vinci 于 2011-01-17 9:42 下午 To xie：
TRILL就是Cisco在推的，與之對應的是IEEE在推的802.1aq(SPB)。這兩個方案都是為了解決STP帶來的問題而提出的。感覺TRILL更正統一些，因為是Perlman大媽主導的，當年也是她搞的STP。但目前TRILL的標準里邊都沒有OAM相關的內容。而SPB由于完全繼承QinQ和PBB，分成SPBV和SPBM兩種模式，也順理成章的繼承了以太網的OAM那一套東西。但是這里又把PBB/PBT這個邊緣化了的東西給弄回來了，好不熱鬧。現在TRILL和SPB都還是draft。
至于后邊怎么發展就拭目以待啦。
#p#
31、Fear 于 2011-01-17 10:03 下午 寫得很好，但我有疑問，VN-tag如何表示虛擬機的Mac地址，從文中描述看，傳到上聯交換機的IP包為網卡Mac+vif_id，網卡Mac表示物理網口，vif_id表示綁定在該物理網口的虛擬網口，如果虛擬機被遷移至另一臺物理機上運行，路由如何修改？IP協議修改了，虛擬機如何跟外網通信？
32、libing 于 2011-01-18 12:00 上午 To Fear
VNTag本身是不攜帶MAC信息的，對現有的vMotion流程也不產生影響，VNTag解決的網絡側對虛擬機的識別和管理問題。
就我的知識范圍，虛擬機遷移后，還是需要通過ARP更新來實現正確尋址。
33、旁觀者清 于 2011-01-18 12:49 上午 To Cius:
Cisco在協議標準化方面對行業的貢獻非常之大，這是有目共睹的。但是，既然是商業公司，畢竟不是研究機構或者慈善機構，必定有其特定的商業目的，不會做虧本的買賣。Cisco投入大量的人力物力在標準化方面，或者說是搶得先機，目的其實再簡單不過了，就是要早一步搶占這塊細分市場，形成對后來者的技術壟斷，如果沒有反壟斷法的制約，天知道會是什么樣的情況，呵呵。效果很明顯，Cisco也是領導行業標準化的最大貢獻者，同時也是最大的受益者。
舉個在中國最簡單的例子，想當年中國的整個金融行業就一種路由協議，EIGRP，放眼望去，都是Cisco的設備。華為搞一個EIGRP，被Cisco給告了最后不了了之，一些其他廠商（我就不點名了），現在還私底下維護EIGRP的代碼和功能，為了能在某個網點可以和Cisco的EIGRP互通。近些年，在其他廠商的集體抗議和抗爭下，OSPF才得以進入到中國的金融行業網絡中…
34、旁觀者清 于 2011-01-18 12:58 上午 To Xie
TRILL是Layer 2 multi-path的“標準化”實現版本，如Da Vinci所言，是Cisco主推的基于二層網絡的基于Mac地址進行“路由”的協議，用了ISIS的協議擴展。Cisco私有的實現叫FabricPath，其實和TRILL幾乎完全一樣。
目前處于Draft狀態，想法很好，感謝Cisco的不斷創新，不過，至于實際可用性還有待未來市場的考驗。
35、libing 于 2011-01-18 1:07 上午 To deltali & Tanglin
Palo除了能配合ESX實現direct I/O，還有一種hypervisor pass thru模式，這種模式也能一定程度地降低CPU負載，增加I/O吞吐，同時保持vMotion等高級功能
36、Lucifer 于 2011-01-18 1:17 上午 passthru模式其實是direct i/o的延伸，本質上是vt-d和sr-iov的配合，網卡本身提供多個logical function（就是多個小的虛擬網卡），然后通過vt-d映射到虛擬機里面。esx本身通過一個驅動模型來解決vmotion遷移到不支持這些技術的機器上的問題
37、Jack_Wang 于 2011-01-18 5:38 上午 虛擬機里分配virtual function ，加載對應 virtual function driver， 與 vmm 中的 physical function driver 通信
38、metal1011 于 2011-01-18 8:35 上午 關注下技術新動態
39、Lucifer 于 2011-01-18 10:16 上午 嗯，是virtual function
40、Lucifer 于 2011-01-18 10:22 上午 虛擬機的virtual function driver不需要和physical function driver通信，是直接和virtual function通信
#p#
41、tom 于 2011-01-25 10:17 下午 請問類似altor，針對虛擬機安全的目前有哪幾家？
42、bigrong 于 2011-01-26 12:04 上午 libing是哪位，是我除了kenealchina、冬瓜頭以外又想拜見的一位大師。好文！
09年的時候思科中國的朋友想讓我寫篇關于nexus的軟文，給了我一堆ppt，還有一個上海的tme給我講了一通，就覺得當時做datacenter，想搞虛擬存儲融合，思科看得真的遠。nexus強不在性能上，而是在內涵上。Juniper的產品更像是美國跑車，快，不會拐彎，沒內涵。
當時對n1000的v和n5k的幾個產品是頗有想法，想仔細研究研究，無奈犯懶，就沒寫。也失去了稿費啊。
早知道當時寫了，即使沒稿費，也能在彎曲得個頭彩，再樹樹我在網絡圈的威。
此次本文，我是服了。好文！
但是，其實我一直有個想法，我們是沿著虛擬化這么看得，復雜之復雜化。
會不會有一個簡單不需要復雜的東西呢？
這樣搞下去，用戶使用成本更高。
43、sclzyb 于 2011-01-26 1:55 上午 1、很奇怪IEEE的trill在05年就提出來，為啥推動得這么慢，現在draft還只是個high-level的狀態，幾個核心問題oam機制，isis擴展，分發樹計算方案都還只是個概念，根據draft還不能做出該功能，特別是控制平面，如DRB選舉之類的東西。
相反SPB這個“棄嬰”反倒找到了數據中心這個應用場景，內容更新得較快。（雖然我個人很不看好SPB的對于trill的競爭）
2、關于vm遷移中的不中斷業務（在線遷移）的方案（IP，mac不變，業務不斷），難道只能是arp的方式來解決，是否有更好的方法，也許兩個管理團隊（網絡管理與服務器管理）的配合能更好的解決這個問題，至少不是等網絡去被動的發現遷移，不過要這兩方配合太不容易：）
3、關于VEPA的實現，我更多的是擔心多播或者廣播的問題，看各位大蝦有比現有draft更好的解決方案
44、CCC 于 2011-01-28 8:32 上午 altor 已經被JUNIPER收購，而且J也不僅僅是快而沒內涵啊？
45、旁觀者清 于 2011-01-29 6:45 下午 to bigrong:
“09年的時候思科中國的朋友想讓我寫篇關于nexus的軟文，給了我一堆ppt，還有一個上海的tme給我講了一通，就覺得當時做datacenter，想搞虛擬存儲融合，思科看得真的遠。nexus強不在性能上，而是在內涵上。Juniper的產品更像是美國跑車，快，不會拐彎，沒內涵。”
原來是專業人士，而且和思科的淵源很深哦，呵呵，佩服佩服，也怪不得沒有稿費還在這里幫Cisco免費打廣告呢，對于您這種敬業的精神很有感觸。。。
順便請教一個小問題，您了解Nexus的歷史嗎，能深入解釋一下為什么Nexus的內涵如此之深嗎？ 我們這些局外人沒有渠道，對此又非常感興趣，希望不吝指教。。。
46、libing 于 2011-02-09 5:48 下午 to bigrong：
高抬了，大師都藏著，我的原意是拋磚引玉。
我覺得你說得很棒，很多時候，我們需要把復雜的實現機制隱藏在簡單的使用界面后面，提供給用戶，用戶用個機器不需要磨練成專家。如果用戶覺得太復雜，那就不是好的解決方案，這個方面，國內很多廠商做的非常好。
To Tom：
類似的產品其實非常多，特別是針對VM的性能和安全監控，數不勝數，但能做得好并跳出來的不多。思科有一個類似的產品VSG，可以看兩眼
http://www.cisco.com/en/US/products/ps11208/index.html
47、tom 于 2011-02-13 9:37 下午 多謝libing，此文章受益匪淺
48、netcache 于 2011-02-27 1:27 上午 回旁觀者清的所有帖子
你說的都是事實，但是流于短視，對于任何公司來說，技術壟斷都是利潤，但是任何壟斷都是短線的利潤，創新才是長期的，對于EIGRP來說更多的是銷售團隊的策略，并不是cisco創建這個協議的本意，至少不全是為了壟斷，多給用戶一個選擇，也不是壞事啊，開個玩笑，您對陰謀論估計研究多了，呵呵
另外給所有關注這個話題的人另外一種觀點，就是拋開云計算來看，高速網絡的發展，已經吧server內部io和網絡io拉得非常近了，如果吧網絡和計算看成是整體，那么每個部分都是組件，長久來看可以簡化服務器的維護，提升網絡的貢獻度，讓用戶像使用交換機那樣使用服務器，從這個角度來看，cisco的vision是要勝過HP的，而且很關鍵一點，無論上FC－BB5還是Fabric path，cisco都不是封閉體系，因此在壟斷的同時也體現了創新
我覺得huawei對cisco的理解還是很到位的，huawei說的“像用自來水一樣使用云計算”可以說是更宏偉的vision
順便說一句，國內用戶的絕大多數問題是自身造成的，試問諸位在哪個項目里面沒有under the table的東西
49、xuesheng 于 2011-03-01 12:52 上午 非常非常不錯的文章，拜讀了好幾遍！
針對7樓的問題我做下解釋，如果虛擬服務器都在vswith上跑，那么虛擬服務器上無法流量監控、無法實施安全策略，管理邊界不清晰，vswitch的問題到底是服務器的問題還是網絡設備的問題。所以必須將vswith上的交換回歸到交換機。
50、陳懷臨 于 2011-03-03 11:52 上午 我也已經讀了3遍，并且到處推薦了。VN-Tag的事情的戰略意義太巨大。。。。。。
我要好好從這個地方開始切入networking的虛擬化。。。
#p#
51、小李 于 2011-03-03 11:48 下午 為什么每次首席的發言都是只說半句話，然后留下一串省略號
讓看得人真的很。。。
52、kernelchina 于 2011-03-04 7:27 上午 VN-tag是全局有效，還是虛擬機與交換機之間有效的？vif是多長字節，圖看不太清楚。Q-in-Q就是為了解決vlan tag不足的問題，vif應該要考慮一下這個問題。
53、陳懷臨 于 2011-03-04 10:02 下午 VN-Tag到了Physical Switch，上行的時候就沒了。
所以，Cisco是要大賣VN-Tag Aware的switch。相對而言，VEPA不需要新設備。
54、一條蟲 于 2011-03-05 1:30 上午 ……如果這樣，VEPA勝算略大。。
55、Will Chie 于 2011-03-05 3:27 上午 客戶需要考慮的很多，產業鏈是否配套，是否有成熟的技術人員能夠管理，總擁有成本等等。
56、呼呼熊 于 2011-03-06 1:01 上午 真是一篇好文章！！
57、owen 于 2011-03-06 2:41 上午 VN-Tag這個是Cisco的私有協議吧，開放給別的廠家如H不?H這些廠家的在VN-TAG和VEPA的取舍態度是如何的呢？
58、tom 于 2011-03-09 5:34 下午 看了下j的5800在dc云的應用，支持VEPA，Qfabric實現了3-2-1中的1，端對端，5800做訪問控制就，加上j收購的altor，可以管理到虛擬機之間的流量，j的方案還是比較完整的，但個疑問，5800的fw性能據朋友說實際測試達到了150G，但如何擴展？多個5800之間如何進行高速交換？
59、旁觀者清 于 2011-03-09 7:19 下午 To Netcache
創新的目的是什么，是搞研究成果申請專利？是為了提出并發布標準？是為了做技術的泰斗把創新的想法和技術普及推廣而得到大家的崇拜？還是是為了人類社會的進化無私的奉獻？
研究機構可能是這樣的，但是商業公司絕對不會是這樣的。商業公司創新的最原始目就是創造利潤，不斷的擴大利潤。創新和技術都是商業公司創造利潤的工具。
思科技術牛，如果不壟斷的話，可以在創新新技術的時候應該邀請華為、邀請Juniper、邀請行業內主流的同領域其他廠商一起交流，共同推進新技術和新標準的發展啊，Cisco的fabricpath里面也放上幾臺華為的交換機，豈不美哉？
如果從Vision的角度，做的最好的還是IBM，要實現智慧的地球，造福全人類。思科也好，華為也罷，還是太短視了，哈哈。
【編輯推薦】
