在二層和三層轉發測試方面(主要是指吞吐量、延時測試),兩者是基本相同的。
buffer性能測試,主要是針對存儲轉發設備的buffer容量的測試。因為不同產品的buffer結構各不相同,所以沒有像RFC那樣標準的測試用例和衡量標準。需要根據不同產品的特征、不同的應用場景和流量模型,進行測試用例設計。
1 二三層轉發性能測試
各廠商的測試儀器都提供了多種測試套件來進行二三層轉發性能測試。具體的測試方法都有詳細說明,這里就不贅述了。本節將重點介紹這些測試套件背后的一些細節問題。
1.1 同步模式和異步模式
使用TestCenter測試時,有一個設置是選擇測試使用同步模式還是異步模式。在端口發送測試流量時,測試儀對發包順序存在一個調度,保證在任意時刻,每一個端口都只唯一收到從一個端口發來的報文,避免在多對多測試時,出現某個時刻,多個端口同時向一個端口發包,產生擁塞的情況。
以8個端口的Full Mesh測試為例,表1表示在某一個時間點(行),每個端口(列)發包的目的端口。
t1 | t2 | t3 | t4 | t5 | t6 | t7 | t8 | t9 | |
P1 | P2 | P3 | P4 | P5 | P6 | P7 | P8 | P1 | P2 |
P2 | P3 | P4 | P5 | P6 | P7 | P8 | P1 | P2 | P3 |
P3 | P4 | P5 | P6 | P7 | P8 | P1 | P2 | P3 | P4 |
P4 | P5 | P6 | P7 | P8 | P1 | P2 | P3 | P4 | P5 |
P5 | P6 | P7 | P8 | P1 | P2 | P3 | P4 | P5 | P6 |
P6 | P7 | P8 | P1 | P2 | P3 | P4 | P5 | P6 | P7 |
P7 | P8 | P1 | P2 | P3 | P4 | P5 | P6 | P7 | P8 |
P8 | P1 | P2 | P3 | P4 | P5 | P6 | P7 | P8 | P1 |
在同步模式中,測試儀器嚴格按照表1中的設置來進行發包。這就保證了任意一個時間點,任意端口都不會同時收到兩個或兩個以上端口發送的報文。這就避免了測試時出現擁塞。
異步模式,是指測試儀器端口并不是嚴格在同一時間點發包,而是按照一個固定的時間差(TestCenter上默認為64us,可配置)來發送。這樣就可能存在某個時刻多個端口會同時向同一個端口發包的情況,產生了擁塞。
同步模式下的性能測試,因為測試儀器保證了不會產生擁塞,所以主要關注的是設備的帶寬,和設備的buffer關系不大;而在異步模式下,測試會產生擁塞,所以需要設備有相對較大的buffer緩存能力,來保證達到線速轉發。
1.2 store-forward與cut-through以及相應的時延
交換機按照處理幀的不同方式分為存儲轉發(store-forward)和直通式(cut-through)。在時延測試時會體現出區別。

圖1 單個報文在交換機中的轉發時刻
如圖1所示,報文在進入交換機到從交換機轉發主要經歷幾個時刻:報文的第一個字節進入交換機的時刻為T1,報文全部進入交換機的時刻T2,報文從交換機端口轉發時的時刻T3,報文全部從交換機端口轉發出去的時刻T4。這幾個時刻之間的差值分別定義為Δ1、Δ2、Δ3。顯然,Δ1和Δ3會受到報文字節長度的影響。
對于store-forward轉發,交換機在轉發之前必須接收整個報文,并且進行錯誤校驗,如果沒有錯誤再發往目的地址。所以報文需要全部進入buffer緩存后,再轉發。也就是說,T3一定是在T2之后,報文的整個轉發流程中,有一部分是buffer內的調度時間Δ2。
對于cut-through轉發,交換機只要檢查到報文頭中所包含的目的地址就立即進行轉發,無需等待報文全部被接收,也不進行錯誤校驗。也就不存在buffer內的調度時間Δ2
根據如上的轉發特征,定義了以下幾種轉發時延類型:
(1)LILO(Last In/Last Out)
指幀的最后一個bit進入設備端口,到幀的最后一個bit從設備端口轉發之間的時間間隔,即報文的轉發時延為T4-T2=Δ2+Δ3。
(2)LIFO(Last In/First Out)
是指幀的最后一個bit進入設備端口,到幀的第一個bit從設備端口轉發之間的時間間隔。即T3-T2=Δ2。這段時間是交換機完全接收到報文后,進行表項查找,buffer調度,再轉發所需要的時間。store-forward方式使用這個時間來衡量時延。可以看出,這種時延計算方式,不受轉發報文的大小影響。
(3)FIFO(First In/First Out)
指幀的第一個bit進入設備端口,到幀的第一個bit從設備端口轉發之間的時間間隔。即T3-T1=Δ1+Δ2 。在cut-through方式下,只要報文頭到達交換機即開始轉發,報文不被緩存,也就沒有Δ2的時間。所以cut-through選用這種時延計算方式。在cut-through方式下,這種方式也不受轉發報文大小的影響。
1.3 混合幀測試/IMIX測試
一般在進行轉發性能測試時,會測試不同長度報文的轉發。
在測試strore-forward方式的設備時,尤其是異步模式下,隨著報文長度的增加,轉發測試時產生的擁塞對于buffer的要求會更高(因為每個報文占用的buffer增多,buffer調度的時間增長)。所以經常發現,隨著報文長度的增加,延時測試的結果會越來越大。對于某些設備,當測試5k以上的jumbo幀時,吞吐量甚至有可能達不到100%。更極端的一種情況,是混合包長的轉發性能測試,也就是IMIX測試,即測試流量是由不同大小的報文按照一定的比例混合組成。通過測試發現,按照混合幀構造流量的測試結果,甚至會比以jumbo幀(例如一個報文9k)構造流量的測試結果更差。這是為什么呢?
因為設備在轉發不同大小報文時,所使用的時間差別很大。以1518和64字節為例,轉發一個1518字節的報文約等于24個64字節報文的轉發時間。當交換機的一個端口在轉發一個大字節報文的過程中,可能會有多個不同字節大小的報文也要從這個端口出去,這就產生了嚴重的擁塞,導致丟包。所以在混合幀的情況下,對Buffer的要求會更高。
1.4 二三層轉發測試時丟包的一般原因
在性能測試過程中,經常會遇到非設備性能因素導致的丟包,對測試產生困擾。這里簡單羅列幾種:
l 測試套上報FCS錯誤。一般是因為某根網線、光纖或某個模塊故障。解決方法為更換網線、光纖或模塊;
l 小字節不丟包,大字節丟包。因為大字節占用buffer資源更多,所以這種情況一般是因為長幀造成的資源不足引起的,可以通過改變buffer設置,來優化測試結果;
l 大字節不丟包,小字節丟包。這種情況一般是由描述符資源限制引起的。部分芯片會為每個報文在其入端口上分配一個報文描述符,相同流量情況下,小字節占用的報文描述符就多;
l MAC HASH沖突。在二層性能測試中,如果使用大量MAC地址測試,可能會出現少量MAC不能被芯片學習的情況,導致部分流量廣播,造成丟包。應先測試設備的MAC HASH能力,然后調整MAC地址的數量;
l 聚合端口HASH不均造成丟包。一般情況下,在多芯片或者堆疊環境中,芯片之間的級聯口,或者堆疊設備之間的堆疊鏈路,都會使用多個高速鏈路的聚合方式來實現。在HASH算法不能保證絕對平均的情況下,會產生某條高速HASH到的流量速率過大,導致的丟包。