【正文】 Mpps。12508與12518都是最大支持9塊交換網(wǎng)板，當(dāng)前主要接口板與N7000相似，含48GE和4萬兆、8萬兆的線速接口板，32萬兆非線速接口板。從背板算起，=9T就是10個槽位的容量，考慮到廠商的宣傳值都是雙向，那么每接口板槽位應(yīng)該是預(yù)留了9000/2/10=450G的最大出口帶寬。根據(jù)12508推算，雙主控每主控板槽位應(yīng)該是預(yù)留(7650/2450*8)/2=。由此背板預(yù)留通道數(shù)接口板與主控板為450:=4:1的關(guān)系?；谑″X原則，主控板上肯定只有一條通道，那么接口板都是4條通道，12508背板槽位一共給接口和主控板留了4*8+2=34條通道。則每條通道的帶寬應(yīng)該是3060/34=90G，由此可以推算出實際每塊接口板的出口帶寬為90*4=360G，則每接口板最大交換即可偶帶寬理論值為180G（比較Cisco N7000的230G理論值要低一些）?！啊钡膶懛☉?yīng)該指新一代的交換網(wǎng)板芯片能力翻倍或者是數(shù)量翻倍，那時其接口板理論帶寬就可以達到360G了，還是小于前面計算的背板預(yù)留450G的最大帶寬，說明背板設(shè)計還是考慮不錯的。再來算算接口板，從8萬兆接口板支持線速轉(zhuǎn)發(fā)看來，首先4個通道應(yīng)該對應(yīng)到4塊轉(zhuǎn)發(fā)芯片，每轉(zhuǎn)發(fā)芯片對應(yīng)2個萬兆接口，處理20G的流量。而32*10G非線速板應(yīng)該是同樣使用4塊轉(zhuǎn)發(fā)芯片，所以也是4:1的收斂比。而其48GE和4*10GE的接口板應(yīng)該是只用了2塊同樣的轉(zhuǎn)發(fā)芯片，每塊轉(zhuǎn)發(fā)芯片對應(yīng)2組12GE接口或2個10GE接口?？紤]其所有接口板采用完全相同轉(zhuǎn)發(fā)芯片是因為大量采購時存在價格優(yōu)勢，不像Cisco自己做芯片。返回來再說下12518，總的通道數(shù)應(yīng)該是18*4+2=74，則總的交換容量應(yīng)該為90*74=。有個小問題，這里的通道數(shù)計算是按照接口板與主控板來統(tǒng)計的，以交換板的角度來看時，12508每塊交換板一個交換芯片要連8塊接口板，每接口板最大4條通道，既需要8*4=32個出口（主控板通道不見得會連接到交換芯片上，也可能是連接到交換網(wǎng)板的CPU）；而12518每塊交換板肯定是兩個交換芯片，每芯片需要18*4/2=36個出口。這說明12500系列交換機網(wǎng)板上的交換芯片要不就都是32出口的，那么12518有2個槽位只有一半的轉(zhuǎn)發(fā)能力；要不就都是36+出口的，12508存在部分出口空余用不上。最后說下包轉(zhuǎn)發(fā)率的計算，機框式交換機的包轉(zhuǎn)發(fā)率應(yīng)該是所有轉(zhuǎn)發(fā)芯片轉(zhuǎn)發(fā)能力的總和。如每個轉(zhuǎn)發(fā)芯片20G處理帶寬（單向），則轉(zhuǎn)發(fā)率應(yīng)該為20/8/(64+20) =，取整為30Mpps。按每接口板最大4個轉(zhuǎn)發(fā)芯片計算，則12508整機為30*4*8=960M，12518為30*4*18=2160M，符合其宣傳值。至于其后面的2400M和5400M兩個值，反向推算，每接口板轉(zhuǎn)發(fā)能力為2400/8=5400/18=300Mpps，帶寬則為300*8*(64+20)=201600約200G，難道是預(yù)示著其下一代接口板能夠使用2個100G的轉(zhuǎn)發(fā)芯片支持2個100G接口，拭目以待。前面算了這么多，希望不會導(dǎo)致頭暈吧。 Clos與VOQ在Crossbar里面，任何兩個轉(zhuǎn)發(fā)芯片之間的只會經(jīng)過一塊交換芯片，路徑是根據(jù)背板固定死的。這就導(dǎo)致了兩個結(jié)構(gòu)性問題的產(chǎn)生：一是多交換芯片時同一對轉(zhuǎn)發(fā)芯片之間的流量不能被負載分擔(dān)，如Cisco N7000就是如此；二是當(dāng)多塊入方向接口板往一塊出方向接口板打流量的時候，流量可能都走到一塊交換芯片上，導(dǎo)致本來應(yīng)該在出接口板發(fā)生的擁塞，提前發(fā)生到交換芯片上，產(chǎn)生結(jié)構(gòu)性擁塞，影響其他經(jīng)過此芯片轉(zhuǎn)發(fā)的流量。而且交換芯片采用CutThrough方式轉(zhuǎn)發(fā)是沒有緩存的，報文都會直接丟棄，對突發(fā)流量的處理不理想。為解決這兩個問題，H3C的12500、Force10的E系列和Foundry BigIron RX等設(shè)備都引入了Clos架構(gòu)的概念（Cisco的CRS系列高端路由器也是Clos結(jié)構(gòu)，但Nexus7000不是）。Clos架構(gòu)是1953年貝爾實驗室研究員Charles Clos設(shè)計的一種多級交換結(jié)構(gòu)，最早應(yīng)用在電話網(wǎng)絡(luò)中。主要是兩個特點，一是可以多級交換，二是每個交換單元都連接到下一級的所有交換單元上。上述廠商設(shè)備中基本都是入接口板交換網(wǎng)板出接口板的3級交換結(jié)構(gòu)，而根據(jù)Clos設(shè)計，后續(xù)交換網(wǎng)可以擴展成多層結(jié)構(gòu)。Crossbar與Clos的主要區(qū)別如下圖所示。全連接的方式滿足了對中間交換芯片的負載均衡需求，同時可以避免單交換芯片的架構(gòu)性阻塞。不過話說回來，目前機框式交換機的轉(zhuǎn)發(fā)能力提升瓶頸還是在轉(zhuǎn)發(fā)芯片上，像前面舉例的N7000和125都是結(jié)構(gòu)轉(zhuǎn)發(fā)能力遠遠大于實際接口板處理能力。所以暫時還不好說Clos就一定是趨勢或代表啥下一代結(jié)構(gòu)，就好像我現(xiàn)在一頓能吃2碗米飯，你給10碗還是20碗對我沒有啥區(qū)別，都得等我胃口先練起來再說，但當(dāng)我胃口真練起來那天，說不定又改吃饅頭了呢。多說一句，H3C的12500在交換芯片轉(zhuǎn)發(fā)流量時，報文是在入接口板先被切成等長信元再交給交換芯片的，到出接口板再組合，有些類似ATM轉(zhuǎn)發(fā)，號稱效率更高。而Force10的E系列則是按報文逐包轉(zhuǎn)發(fā)，號稱是為了避免亂序等問題。又是各有道理，管他呢，不出問題就什么都好。目前新的分布式轉(zhuǎn)發(fā)交換機另一項重要的技術(shù)就是VOQ（Virtual Output Queues）。剛才說的Crossbar第二個擁塞問題在Clos架構(gòu)中，雖然流量不會在Switch Fabric擁塞，但是多打一的情況下仍然會在出接口板擁塞。VOQ就是在入接口板將報文發(fā)給Switch Fabric之前，先用VOQ緩存一下，然后通過中央裁決線路，發(fā)一個問詢給出接口板，看看那邊還有沒有空間接收，有的話就發(fā)，沒有先緩存一會兒，和FC網(wǎng)絡(luò)中實現(xiàn)零丟包的Bufer to Bufer Credit機制很相似（BB Credit機制詳見下文FCoE技術(shù)部分）。這樣就使出接口板的緩存能力擴充到多塊入接口板上，容量翻倍提升，可以有效的緩解突發(fā)擁塞導(dǎo)致的丟包問題?？聪聢DCisco N7000的8口萬兆板結(jié)構(gòu)圖可以較好理解VOQ在接口板中的位置。 網(wǎng)絡(luò)小結(jié)數(shù)據(jù)中心網(wǎng)絡(luò)看交換，交換機發(fā)展看芯片，分布式轉(zhuǎn)發(fā)是必然，Clos架構(gòu)有得盼。本章內(nèi)容是下文數(shù)據(jù)中心內(nèi)部服務(wù)器通信網(wǎng)絡(luò)發(fā)展技術(shù)的重要鋪墊。充分了解機框式交換機，可以對后面提出的新一代數(shù)據(jù)中心網(wǎng)絡(luò)虛擬化技術(shù)，（如Cisco的VNTag、Fabric Extend和Fabric Path/ETRILL等）在理解時起到巨大的幫助。題外話，目前很多企業(yè)規(guī)模大了以后，網(wǎng)絡(luò)部門負責(zé)網(wǎng)絡(luò)，業(yè)務(wù)部門負責(zé)應(yīng)用和服務(wù)器，很多時候互不搭界，于是設(shè)計網(wǎng)絡(luò)和應(yīng)用的時候就各搞各的，等數(shù)據(jù)中心建起來之后發(fā)現(xiàn)這也是問題那也是問題，各個都變身救火隊員，不是啥好現(xiàn)象。有一本書建議所有的網(wǎng)絡(luò)規(guī)劃設(shè)計人員翻看，《自頂向下的網(wǎng)絡(luò)設(shè)計》，即使找不到或沒時間看也請一定要記住這個書名，終身受益的。對應(yīng)用業(yè)務(wù)設(shè)計人員，也請稍微了解下網(wǎng)絡(luò)，最少也得能估算出業(yè)務(wù)上線后理論上的平均帶寬和峰值帶寬，好向網(wǎng)絡(luò)設(shè)計人員提出需求，免得出事時焦頭爛額互相推諉。5 技術(shù)終于到本文的根本了，前面balabala的說了那么多，都是本章的鋪墊，就是希望大家明白下面這些技術(shù)是為何而來，要解決什么樣的需求和問題。再次對前面的需求進行個匯總。VM之間的互通更多的接口，更多的帶寬二層網(wǎng)絡(luò)規(guī)模擴大數(shù)據(jù)中心站點間二層互聯(lián)VM跨站點遷移與多站點選路服務(wù)器前后端網(wǎng)絡(luò)融合（這個屬于廠家引導(dǎo)還是用戶需求真不好說）下面就來看看下面這些網(wǎng)絡(luò)技術(shù)是如何解決上述需求問題的。 技術(shù)結(jié)構(gòu)前面說了，數(shù)據(jù)中心網(wǎng)絡(luò)流量的根本出發(fā)點是Server，結(jié)合云計算最適合的核心接入二層網(wǎng)絡(luò)結(jié)構(gòu)，可以把下面要介紹的各種技術(shù)分類如下圖所示。此處只做結(jié)構(gòu)上的介紹，具體技術(shù)細節(jié)將在下文展開。Network1VM本地互訪網(wǎng)絡(luò)，邊界是Access Switch，包括物理服務(wù)器本機VM互訪和跨Access Switch的不同物理服務(wù)器VM互訪兩個層面。原有技術(shù)以服務(wù)器內(nèi)部安裝軟件虛擬交換機VSwitch為主， EVB（VEPA/Multichannel） BPE（Port Extend/VNTag/VNLink）兩大IEEE標(biāo)準(zhǔn)體系。Network2Ethernet與FC融合，就是FCoE，邊界仍然是Access Switch。在服務(wù)器物理網(wǎng)卡到Access Switch這段，將FC數(shù)據(jù)承載在Ethernet的某個VLAN中傳輸。但實際上各個廠商當(dāng)前實現(xiàn)都是做NPV交換機，并不是真正的FCoE，只有很少的產(chǎn)品如Cisco的Nexus5000系列和Brocade的8000系列等能夠支持做FCF。Network3跨核心層服務(wù)器互訪網(wǎng)絡(luò)，邊界是Access Switch與Core Switch。可理解為服務(wù)器互訪流量從進入Access Switch，經(jīng)過Core Switch，再從另一個Access Switch轉(zhuǎn)出過程的網(wǎng)絡(luò)處理技術(shù)。原有技術(shù)就是STP了，新技術(shù)分為設(shè)備控制平面虛擬化（VSS/vPC/IRF）和整網(wǎng)數(shù)據(jù)平面虛擬化（SPB/TRILL/Fabric Path）兩大體系。這兩個體系都是網(wǎng)絡(luò)虛擬化中的多虛一方向，在一虛多方向除去傳統(tǒng)的VLAN/VRF外，Cisco的N7000系列還依照X86架構(gòu)虛擬化整出了個VDC。Network4數(shù)據(jù)中心跨站點二層網(wǎng)絡(luò)，邊界是Core Switch。目標(biāo)是跨越核心網(wǎng)為多個數(shù)據(jù)中心站點的Core Switch之間建立一條二層通道。根據(jù)站點間互聯(lián)核心網(wǎng)的區(qū)別，分為以下三類技術(shù)：l 光纖直連（SDH/DWDM等）對應(yīng)Ethernet（RPR）l MPLS核心網(wǎng)對以L2VPN（VLL/VPLS）l IP核心網(wǎng)對應(yīng)IP隧道技術(shù)（VLLoGRE/VPLSoGRE/L2TPv3/OTV）Cisco的OTV雖然主要應(yīng)用在IP核心網(wǎng)中，但實際前面兩種方式下同樣可以使用，只要多個數(shù)據(jù)中心站點的Core Switch設(shè)備間能夠建立可達的IP路徑即可部署。使用VLL/VPLS相關(guān)技術(shù)時必須要增加專門的PE設(shè)備為站點間的Core Switch建立二層隧道，而OTV可以直接部署在Core Switch上。Network5數(shù)據(jù)中心多站點選擇，技術(shù)邊界在數(shù)據(jù)中心與廣域網(wǎng)相連的邊緣。在云計算中，VM跨站點遷移后，業(yè)務(wù)服務(wù)器IP地址不變，網(wǎng)絡(luò)指向需要隨之變化。這塊前面也提到現(xiàn)有技術(shù)就是DNS域名解析與ServerLB的NAT配合，以及主機IP路由發(fā)布等方式。新技術(shù)則是Cisco提出LISP以IPinIP技術(shù)結(jié)構(gòu)繞開DNS，由網(wǎng)絡(luò)設(shè)備單獨處理Client在廣域網(wǎng)中選擇站點的情況。 網(wǎng)絡(luò)虛擬化云計算就是計算虛擬化，而存儲虛擬化已經(jīng)在SAN上實現(xiàn)得很好了，那么數(shù)據(jù)中心三大件也就剩下網(wǎng)絡(luò)虛擬化了。那么為什么要搞網(wǎng)絡(luò)虛擬化呢？還是被計算逼的。云計算多虛一時，所有的服務(wù)資源都成為了一個對外的虛擬資源，那么網(wǎng)絡(luò)不管是從路徑提供還是管理維護的角度來說，都得跟著把一堆的機框盒子進行多虛一統(tǒng)一規(guī)劃。而云計算一虛多的時候，物理服務(wù)器都變成了一堆的VM，網(wǎng)絡(luò)怎么也要想辦法搞個一虛多對通路建立和管理更精細化一些不是。 網(wǎng)絡(luò)多虛一技術(shù)先說網(wǎng)絡(luò)多虛一技術(shù)。最早的網(wǎng)絡(luò)多虛一技術(shù)代表是交換機集群Cluster技術(shù)，多以盒式小交換機為主，較為古老，當(dāng)前數(shù)據(jù)中心里面已經(jīng)很少見了。而新的技術(shù)則主要分為兩個方向，控制平面虛擬化與數(shù)據(jù)平面虛擬化?？刂破矫嫣摂M化顧名思義，控制平面虛擬化是將所有設(shè)備的控制平面合而為一，只有一個主體去處理整個虛擬交換機的協(xié)議處理，表項同步等工作。從結(jié)構(gòu)上來說，控制平面虛擬化又可以分為縱向與橫向虛擬化兩種方向。縱向虛擬化指不同層次設(shè)備之間通過虛擬化合多為一，代表技術(shù)就是Cisco的Fabric Extender，相當(dāng)于將下游交換機設(shè)備作為上游設(shè)備的接口擴展而存在，虛擬化后的交換機控制平面和轉(zhuǎn)發(fā)平面都在上游設(shè)備上，下游設(shè)備只有一些簡單的同步處理特性，報文轉(zhuǎn)發(fā)也都需要上送到上游設(shè)備進行。可以理解為集中式轉(zhuǎn)發(fā)的虛擬交換機橫向虛擬化多是將同一層次上的同類型交換機設(shè)備虛擬合一， Cisco的VSS/vPC和H3C的IRF都是比較成熟的技術(shù)代表，控制平面工作如縱向一般，都由一個主體去完成，但轉(zhuǎn)發(fā)平面上所有的機框和盒子都可以對流量進行本地轉(zhuǎn)發(fā)和處理，是典型分布式轉(zhuǎn)發(fā)結(jié)構(gòu)的虛擬交換機。Juniper的QFabric也屬于此列，區(qū)別是單獨弄了個Director盒子只作為控制平面存在，而所有的Node QFX3500交換機同樣都有自己的轉(zhuǎn)發(fā)平面可以處理報文進行本地轉(zhuǎn)發(fā)。控制平面虛擬化從一定意義上來說是真正的虛擬交換機，能夠同時解決統(tǒng)一管理與接口擴展的需求。但是有一個很嚴(yán)重的問題制約了其技術(shù)的發(fā)展。在前面的云計算多虛一的時候也提到過，服務(wù)器多虛一技術(shù)目前無法做到所有資源的靈活虛擬調(diào)配，而只能基于主機級別，當(dāng)多機運行時，協(xié)調(diào)者的角色（等同于框式交換機的主控板控制平面）對同一應(yīng)用來說，只能主備，無法做到負載均衡。網(wǎng)絡(luò)設(shè)備虛擬化也同樣如此，以框式設(shè)備舉例，不管以后能夠支持多少臺設(shè)備虛擬合一，只要不能解決上述問題，從控制平面處理整個虛擬交換機運行的物理控制節(jié)點主控板都只能有一塊為主，其他都是備份角色（類似于服務(wù)器多虛一中的HA Cluster結(jié)構(gòu)）?？偠灾?，虛擬交換機支持的物理節(jié)點規(guī)模永遠會受限于此控制節(jié)點的處理能力。這也是Cisco在6500系列交換機的VSS技術(shù)在更新?lián)Q代到Nexus7000后被砍掉，只基于鏈路聚合做了個vPC的主要原因。三層IP網(wǎng)絡(luò)多路徑已經(jīng)有等價路由可以用了，二層Ethernet網(wǎng)絡(luò)的多路徑技術(shù)在TRILL/SPB實用之前只有一個鏈路聚合，所以只做個vPC就足矣了。另外從Cisco的FEX技術(shù)只應(yīng)用于數(shù)據(jù)中心接入層的產(chǎn)品設(shè)計，也能看出其對這種控制平面虛擬化后帶來的規(guī)模限制以及技術(shù)應(yīng)用位置是非常清晰的。數(shù)據(jù)平面虛擬化前面說了控制平面虛擬化帶來的規(guī)模限制問題，而且短時間內(nèi)也沒有辦法解決，那么就想個法子躲過去。能不能只做數(shù)據(jù)平面的虛擬化呢，于是有了TRILL和SPB。關(guān)于兩個協(xié)議的具體細節(jié)下文會進行展開，這里先簡單說一下，他們都是用L2 ISIS作為控制協(xié)議在所有設(shè)備上進行拓撲路徑計算，轉(zhuǎn)發(fā)的時候