簡(jiǎn)介這份思博倫網(wǎng)絡(luò)分析儀使用手冊(cè)面向網(wǎng)絡(luò)工程師、系統(tǒng)管理員及IT技術(shù)支持人員幫助其系統(tǒng)掌握該品牌網(wǎng)絡(luò)分析儀的硬件連接、軟件操作與安全配置。手冊(cè)從儀器物理結(jié)構(gòu)、接口功能與設(shè)備連接講起逐步深入到軟件界面的菜單欄、工具欄使用以及測(cè)試參數(shù)設(shè)置、數(shù)據(jù)包捕獲和報(bào)告解讀同時(shí)涵蓋密碼保護(hù)、用戶權(quán)限管理與數(shù)據(jù)備份恢復(fù)等安全操作并配有實(shí)踐案例與故障排除指導(dǎo)附錄還提供技術(shù)參數(shù)、協(xié)議列表和命令參考。資源包共2000個(gè)文件以1837個(gè)htm網(wǎng)頁(yè)文檔為主體輔以87個(gè)js腳本、70個(gè)xml配置、4個(gè)css樣式另含1份pdf與1份docx手冊(cè)壓縮后約21.76MB目錄結(jié)構(gòu)便于按模塊查閱。目前已有145人學(xué)習(xí)適合需要快速上手設(shè)備操作、排查網(wǎng)絡(luò)故障或深入理解測(cè)試流程的讀者參考。1. 思博倫網(wǎng)絡(luò)分析儀使用手冊(cè)從開箱到跑通第一條流機(jī)房角落里那臺(tái)思博倫網(wǎng)絡(luò)分析儀多半不是壞在硬件上而是壞在沒人記得住它那套測(cè)試套件的操作路徑。我見過太多團(tuán)隊(duì)把它當(dāng)“高級(jí)打流儀”用插上光模塊、配個(gè) IP、點(diǎn)開始然后盯著一個(gè)不動(dòng)的計(jì)數(shù)器發(fā)呆——問題往往出在端口模式?jīng)]切、流模板沒綁對(duì)、或者 license 根本沒認(rèn)到那塊測(cè)試模塊。思博倫網(wǎng)絡(luò)分析儀使用手冊(cè)要解決的核心就是把這臺(tái)設(shè)備從“黑匣子”變成可復(fù)現(xiàn)的測(cè)試平臺(tái)端口怎么配、流怎么建、RFC2544 和 RFC6349 這類標(biāo)準(zhǔn)套件怎么跑、結(jié)果怎么讀。它適合網(wǎng)絡(luò)設(shè)備驗(yàn)證工程師、數(shù)通產(chǎn)品測(cè)試崗以及需要做吞吐/時(shí)延/丟包基準(zhǔn)測(cè)試的運(yùn)維骨干。手冊(cè)不是讓你背命令而是讓你在換板卡、換版本、換被測(cè)設(shè)備DUT時(shí)能自己把鏈路重新拉通。2. 思博倫網(wǎng)絡(luò)分析儀測(cè)試前必須鎖死的四個(gè)配置層2.1 機(jī)框、板卡與端口映射先讓軟件認(rèn)出硬件思博倫的測(cè)試平臺(tái)通常由機(jī)框chassis、測(cè)試模塊test module和端口port三層組成。很多人一上來就打開 TestCenter 或 Avalanche 界面找端口結(jié)果列表里空空如也第一反應(yīng)是“設(shè)備壞了”。其實(shí)多數(shù)情況是管理口和測(cè)試口不在同一網(wǎng)段或者機(jī)框的 IP 被改過而客戶端還連著舊地址。我一般按這個(gè)順序確認(rèn)硬件可見性# 在測(cè)試客戶端上先確認(rèn)到機(jī)框管理口的連通性 ping 192.168.1.100 # 思博倫常見的管理端口是 4000 和 8080用 telnet 探一下服務(wù)是否在聽 telnet 192.168.1.100 4000如果 ping 通但端口連不上優(yōu)先查機(jī)框的 slot 電源和模塊狀態(tài)。思博倫的模塊前面板有 LED正常上電后應(yīng)該是綠色常亮或慢閃如果某個(gè) slot 燈不亮軟件里也不會(huì)出現(xiàn)對(duì)應(yīng)端口。這一步?jīng)]有捷徑物理層不通后面所有流配置都是空中樓閣。參數(shù)上要特別注意機(jī)框管理 IP、子網(wǎng)掩碼、網(wǎng)關(guān)這三項(xiàng)必須和測(cè)試客戶端在同一廣播域或者至少有可達(dá)路由。有些實(shí)驗(yàn)室把管理口接在帶外交換機(jī)上測(cè)試口接在帶內(nèi)這時(shí)候客戶端需要雙網(wǎng)卡分別連兩個(gè)網(wǎng)段否則軟件能發(fā)現(xiàn)機(jī)框但發(fā)現(xiàn)不了模塊。2.2 端口模式L1 層要選對(duì)介質(zhì)和速率思博倫的端口配置里有一個(gè)容易被忽略的選項(xiàng)端口模式Port Mode。它決定了這個(gè)物理口是以 1000BASE-X、10GBASE-R 還是 25GBASE-R 等方式工作。如果你插的是 10G 光模塊但端口模式還停在 1G軟件會(huì)顯示鏈路 down或者更隱蔽地顯示 up 但打流全丟。常見做法是先在端口屬性里把 Media 選成 Fiber 或 Copper再選 Speed。對(duì)于光口還要確認(rèn) FEC 模式25G 和 100G 場(chǎng)景下RS-FEC 和 FC-FEC 選錯(cuò)會(huì)導(dǎo)致鏈路起不來。我遇到過 DUT 側(cè)強(qiáng)制 RS-FEC 而思博倫側(cè)默認(rèn) None結(jié)果兩邊都顯示 link up但一打流就大量 CRC 錯(cuò)包。后來把兩邊 FEC 都改成 RS-FEC 才穩(wěn)定。# 思博倫 TestCenter 的 REST API 示例查詢端口狀態(tài) curl -s -X GET http://192.168.1.100:4000/api/v1/ports/1/1 \ -H Content-Type: application/json \ -u admin:admin返回的 JSON 里重點(diǎn)看linkStatus、mediaType、speed和fecMode四個(gè)字段。如果linkStatus是DOWN先別急著改流回到物理層查光模塊型號(hào)和光纖跳線。多模和單?；煊谩⒉ㄩL(zhǎng)不匹配都會(huì)讓鏈路看起來“插好了”但實(shí)際不通。2.3 License 與功能包RFC2544 不是默認(rèn)就能跑思博倫的很多測(cè)試套件是 license 控制的。機(jī)框能發(fā)現(xiàn)、端口能 up不代表你就能跑 RFC2544 吞吐測(cè)試。如果 license 里沒有包含對(duì)應(yīng)的性能測(cè)試包界面上那個(gè)“RFC2544”按鈕可能是灰的或者點(diǎn)進(jìn)去提示 feature not enabled。我一般會(huì)在正式測(cè)試前做一次 license 盤點(diǎn)功能項(xiàng)常見 license 名稱不包含時(shí)的現(xiàn)象RFC2544 基準(zhǔn)測(cè)試Performance Test套件入口灰色或報(bào)錯(cuò)RFC6349 TCP 吞吐TCP Throughput無法選擇 TCP 層測(cè)試路由協(xié)議仿真Routing/BGP協(xié)議樹里沒有 BGP 選項(xiàng)安全攻擊仿真Security Test攻擊流模板庫(kù)為空如果發(fā)現(xiàn)缺 license不要試圖用“通用打流”去模擬 RFC2544 的階梯加壓那樣得到的數(shù)字沒有可比性。正確做法是聯(lián)系設(shè)備管理員確認(rèn) license 服務(wù)器地址或者在機(jī)框本地導(dǎo)入 license 文件。導(dǎo)入后通常需要重啟測(cè)試服務(wù)不是重啟整個(gè)機(jī)框。2.4 測(cè)試客戶端版本與機(jī)框固件匹配思博倫的測(cè)試客戶端軟件版本和機(jī)框固件版本之間有兼容矩陣。我踩過一次血淚坑客戶端升到最新版機(jī)框還是兩年前的固件結(jié)果端口能發(fā)現(xiàn)但一配置流就報(bào)“unsupported attribute”。后來查兼容表才發(fā)現(xiàn)新版客戶端用了新的流屬性字段舊固件不認(rèn)。穩(wěn)妥做法是在升級(jí)客戶端之前先確認(rèn)機(jī)框固件版本然后去思博倫支持站點(diǎn)查兼容矩陣。如果機(jī)框固件太舊要么降客戶端版本要么安排停機(jī)窗口升固件。固件升級(jí)通常通過機(jī)框的 Web 管理界面或 USB 完成升級(jí)過程中不能斷電否則模塊可能變磚。3. 用 TestCenter 跑通 RFC2544 吞吐測(cè)試的完整步驟3.1 建立端口對(duì)與流模板先讓包能發(fā)出去RFC2544 吞吐測(cè)試的本質(zhì)是在兩個(gè)端口之間建立雙向流從零開始階梯式增加負(fù)載直到出現(xiàn)丟包然后記錄不丟包的最大速率。在思博倫 TestCenter 里第一步是選兩個(gè)端口一個(gè)作為發(fā)送端一個(gè)作為接收端然后創(chuàng)建流模板。我一般用“Quick Test”向?qū)扰芤粋€(gè)最小閉環(huán)確認(rèn)包能正常收發(fā)再切到 RFC2544 套件。最小閉環(huán)的流配置如下# 思博倫 TestCenter Python API 示例創(chuàng)建一條簡(jiǎn)單的 UDP 流 from stcrestclient import stchttp stc stchttp.StcHttp(192.168.1.100) stc.session_id stc.new_session(RFC2544_Test, admin) # 創(chuàng)建兩個(gè)端口對(duì)象 port1 stc.create(port, understc.project, attributes{Location: //192.168.1.100/1/1}) port2 stc.create(port, understc.project, attributes{Location: //192.168.1.100/1/2}) # 創(chuàng)建流模板 stream stc.create(stream, underport1, attributes{ FrameLength: 512, FrameCount: 1000, Rate: 1000000 # 1 Mbps 起步 }) # 綁定接收端 stc.create(stream, underport2, attributes{FrameLength: 512})這段代碼的邏輯是在端口 1 上創(chuàng)建一條 512 字節(jié)、1000 個(gè)包、速率 1 Mbps 的流端口 2 作為接收端。參數(shù)里FrameLength決定包長(zhǎng)RFC2544 通常要求測(cè) 64、128、256、512、1024、1280、1518 字節(jié)七種包長(zhǎng)Rate是初始速率后續(xù)階梯加壓會(huì)從這個(gè)值開始翻倍或按步長(zhǎng)增加。跑之前一定要點(diǎn)“Preview”或“Analyze”檢查流是否綁定正確。常見錯(cuò)誤是流建在了端口 1但接收端沒綁端口 2結(jié)果發(fā)出去的包全被當(dāng)成未知單播丟棄計(jì)數(shù)器里只有 Tx 沒有 Rx。3.2 RFC2544 套件參數(shù)迭代次數(shù)、步長(zhǎng)和丟包門限進(jìn)入 RFC2544 套件后有幾個(gè)參數(shù)直接決定測(cè)試時(shí)長(zhǎng)和結(jié)果可信度Test Iterations每個(gè)包長(zhǎng)重復(fù)測(cè)幾次。默認(rèn) 1 次我一般設(shè) 3 次取平均減少偶發(fā)丟包導(dǎo)致的誤判。Step Size階梯加壓的步長(zhǎng)。默認(rèn) 10%如果 DUT 性能曲線比較陡可以降到 5%如果只想快速摸底可以設(shè) 20%。Loss Threshold丟包門限。RFC2544 標(biāo)準(zhǔn)定義吞吐量為“零丟包”的最大速率但實(shí)際測(cè)試中可以把門限設(shè)成 0.001%避免因?yàn)橐粋€(gè)包的抖動(dòng)就判定失敗。Duration每步持續(xù)時(shí)間。默認(rèn) 10 秒對(duì)于高負(fù)載場(chǎng)景可以延長(zhǎng)到 30 秒讓 DUT 的緩存和隊(duì)列行為充分暴露。這些參數(shù)在套件界面上都有輸入框改完后點(diǎn)“Start”就會(huì)自動(dòng)跑完所有包長(zhǎng)和所有階梯。跑的過程中可以看實(shí)時(shí)曲線橫軸是速率縱軸是丟包率。如果曲線在某個(gè)速率點(diǎn)突然從 0 跳到 5% 以上說明 DUT 的轉(zhuǎn)發(fā)瓶頸就在那附近。3.3 結(jié)果解讀吞吐量、時(shí)延和丟包率怎么看RFC2544 跑完后會(huì)生成一份報(bào)告核心指標(biāo)有三個(gè)指標(biāo)含義正常表現(xiàn)Throughput零丟包最大速率接近線速或 DUT 標(biāo)稱值Latency存儲(chǔ)轉(zhuǎn)發(fā)時(shí)延隨負(fù)載增加緩慢上升Frame Loss丟包率在吞吐量以下應(yīng)為 0如果吞吐量遠(yuǎn)低于線速先別懷疑 DUT。檢查思博倫端口是否協(xié)商到了正確速率流模板里的包長(zhǎng)是否和測(cè)試項(xiàng)一致以及接收端是否開了過濾導(dǎo)致部分包被丟棄。我見過一次 10G 端口只跑出 2G 吞吐最后發(fā)現(xiàn)是光模塊是 1G 的端口模式?jīng)]改。時(shí)延數(shù)據(jù)要結(jié)合 DUT 的轉(zhuǎn)發(fā)模式看。存儲(chǔ)轉(zhuǎn)發(fā)設(shè)備的時(shí)延通常隨包長(zhǎng)增加而增加因?yàn)橐胀暾麄€(gè)包才轉(zhuǎn)發(fā)直通式設(shè)備時(shí)延基本恒定。如果時(shí)延曲線出現(xiàn)臺(tái)階式跳變可能是 DUT 內(nèi)部隊(duì)列調(diào)度策略在起作用這時(shí)候要結(jié)合 DUT 的 QoS 配置一起分析。4. 思博倫網(wǎng)絡(luò)分析儀避坑與排查五個(gè)讓我加班到凌晨的坑4.1 端口 up 但打流全丟FEC 和自協(xié)商不匹配現(xiàn)象思博倫端口和 DUT 端口都顯示 link up但一打流Tx 計(jì)數(shù)正常Rx 計(jì)數(shù)為零或者只有少量包且 CRC 錯(cuò)誤暴增。原因光口場(chǎng)景下FEC 模式不匹配是最常見的原因。25G/100G 以太網(wǎng)默認(rèn)可能開啟 RS-FEC而思博倫端口如果設(shè)成 None 或 FC-FEC鏈路層能 up但數(shù)據(jù)幀在物理編碼層就被丟棄。另一個(gè)原因是自協(xié)商Auto-Negotiation雙方不一致一方強(qiáng)制、一方自協(xié)商導(dǎo)致雙工模式或速率實(shí)際不匹配。解決先把兩邊端口都設(shè)成自協(xié)商確認(rèn)鏈路穩(wěn)定后再嘗試強(qiáng)制模式。FEC 方面查 DUT 側(cè)配置思博倫側(cè)設(shè)成相同模式。如果不確定用show interfaces類命令看 DUT 的 FEC 狀態(tài)然后在思博倫端口屬性里對(duì)齊。4.2 RFC2544 套件灰色不可點(diǎn)license 沒認(rèn)到現(xiàn)象TestCenter 界面里 RFC2544 入口是灰色的或者點(diǎn)進(jìn)去提示“Feature not licensed”。原因機(jī)框的 license 文件里沒有包含 Performance Test 功能包或者 license 服務(wù)器連接失敗導(dǎo)致臨時(shí)授權(quán)沒拉取到。解決在機(jī)框 Web 管理界面查看 license 狀態(tài)確認(rèn) Performance Test 是否在列。如果 license 是浮動(dòng)式的檢查 license 服務(wù)器 IP 和端口是否可達(dá)。導(dǎo)入 license 后重啟 TestCenter 服務(wù)而不是整個(gè)機(jī)框通常幾十秒就能生效。4.3 流模板綁定錯(cuò)端口Tx 有數(shù) Rx 為零現(xiàn)象流已經(jīng)創(chuàng)建Start 之后 Tx 計(jì)數(shù)器在漲但 Rx 始終為零DUT 側(cè)也看不到任何包。原因流模板創(chuàng)建在了錯(cuò)誤的端口下或者接收端沒有綁定到對(duì)應(yīng)的流。思博倫的流是單向的發(fā)送流和接收流需要分別綁定。如果只建了發(fā)送流接收端不會(huì)自動(dòng)關(guān)聯(lián)。解決在流配置界面檢查每個(gè)流的“Binding”屬性確認(rèn)發(fā)送流綁在端口 1接收流綁在端口 2。用“Preview”功能可以看到每個(gè)端口上的流列表如果接收端列表為空說明綁定漏了。4.4 測(cè)試結(jié)果波動(dòng)大背景流量和 DUT 緩存沒清現(xiàn)象同一配置跑三次 RFC2544吞吐量結(jié)果相差 20% 以上。原因?qū)嶒?yàn)室里其他設(shè)備在打背景流量或者 DUT 的緩存和會(huì)話表沒清空上一次測(cè)試的殘留狀態(tài)影響了本次結(jié)果。解決測(cè)試前在思博倫上抓一段空載流量確認(rèn)背景噪聲低于線速的 0.1%。DUT 側(cè)重啟或清空會(huì)話表等設(shè)備完全 idle 后再開始。如果 DUT 有動(dòng)態(tài)路由協(xié)議等路由收斂穩(wěn)定后再打流。4.5 客戶端連不上機(jī)框管理網(wǎng)段和防火墻現(xiàn)象測(cè)試客戶端 ping 不通機(jī)框管理 IP或者能 ping 通但 TestCenter 連不上。原因客戶端和機(jī)框不在同一網(wǎng)段且沒有路由或者中間防火墻攔了 4000/8080 端口。解決先用traceroute確認(rèn)路徑然后在客戶端上telnet 機(jī)框IP 4000測(cè)試端口可達(dá)性。如果防火墻攔了申請(qǐng)放行或把客戶端接到機(jī)框同一交換機(jī)上。有些機(jī)框支持雙管理口確認(rèn)你連的是當(dāng)前活躍的那個(gè)。5. 用 Python 腳本批量跑 RFC2544 并自動(dòng)導(dǎo)出報(bào)告手動(dòng)在界面上點(diǎn) RFC2544 適合摸底但如果你要測(cè)幾十個(gè)包長(zhǎng)組合、或者每天跑回歸腳本化是唯一出路。思博倫提供 REST API 和 Python 庫(kù)我一般用stcrestclient做批量測(cè)試。下面是一個(gè)批量跑七種包長(zhǎng)并導(dǎo)出 CSV 的腳本骨架import csv from stcrestclient import stchttp # 連接機(jī)框 stc stchttp.StcHttp(192.168.1.100) stc.session_id stc.new_session(Batch_RFC2544, admin) # 包長(zhǎng)列表 frame_sizes [64, 128, 256, 512, 1024, 1280, 1518] results [] for size in frame_sizes: # 配置流模板的包長(zhǎng) stream stc.get(stream, understc.project, attributes{FrameLength: size}) stc.config(stream, {FrameLength: size}) # 啟動(dòng) RFC2544 套件假設(shè)已預(yù)配置好 rfc_test stc.get(rfc2544test, understc.project) stc.perform(StartTest, rfc_test) # 等待測(cè)試完成實(shí)際使用中需要輪詢狀態(tài) import time while stc.get(rfc2544test, understc.project).Status ! COMPLETED: time.sleep(5) # 讀取吞吐量結(jié)果 throughput stc.get(rfc2544test, understc.project).Throughput results.append({FrameSize: size, Throughput_Mbps: throughput}) # 導(dǎo)出 CSV with open(rfc2544_results.csv, w, newline) as f: writer csv.DictWriter(f, fieldnames[FrameSize, Throughput_Mbps]) writer.writeheader() writer.writerows(results) stc.end_session()這段腳本的關(guān)鍵點(diǎn)在于每次改包長(zhǎng)后要重新配置流模板然后啟動(dòng)套件并輪詢狀態(tài)直到完成。實(shí)際使用中StartTest和狀態(tài)查詢的 API 名稱可能因版本不同而有差異需要查對(duì)應(yīng)版本的 API 文檔。參數(shù)上FrameLength直接對(duì)應(yīng) RFC2544 的七種包長(zhǎng)Throughput返回的是該包長(zhǎng)下的零丟包最大速率。跑完腳本后我會(huì)用 pandas 做一次快速可視化看吞吐量隨包長(zhǎng)的變化曲線。正常情況下小包吞吐量低、大包吞吐量高因?yàn)樾“膯挝晦D(zhuǎn)發(fā)開銷更大。如果曲線出現(xiàn)反常的下降比如 512 字節(jié)比 64 字節(jié)還低那就要查 DUT 的 QoS 策略或者思博倫的流配置是否有誤。最后說一個(gè)我自己的習(xí)慣每次測(cè)試前先跑一個(gè) 64 字節(jié)、1 Mbps 的最小流確認(rèn) Tx 和 Rx 計(jì)數(shù)一致再開始正式套件。這個(gè)動(dòng)作花不到一分鐘但能省掉后面半小時(shí)的排查。思博倫網(wǎng)絡(luò)分析儀使用手冊(cè)里的功能很多但真正高頻用到的就是端口配置、流模板、RFC2544 和結(jié)果導(dǎo)出這四塊。把這四塊跑熟剩下的套件都是類似的邏輯。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取