2025年網(wǎng)絡(luò)測試與故障診斷期末試題及答案一、單項選擇題（每題2分，共30分）1.某企業(yè)局域網(wǎng)中，用戶反饋訪問內(nèi)部文件服務(wù)器時丟包率高達15%，但訪問互聯(lián)網(wǎng)正常。使用Wireshark抓包發(fā)現(xiàn)，客戶端與服務(wù)器之間的TCP報文存在大量重復的ACK。最可能的故障原因是（）A.出口路由器到ISP的鏈路擁塞B.文件服務(wù)器的CPU利用率過高C.客戶端與服務(wù)器之間的交換機端口速率不匹配D.DNS服務(wù)器解析延遲答案：B（TCP重復ACK通常由接收方處理延遲導致，可能是服務(wù)器處理能力不足）2.測試Wi-Fi7網(wǎng)絡(luò)的漫游性能時，需重點關(guān)注的指標是（）A.信道帶寬B.切換延遲C.發(fā)射功率D.調(diào)制方式答案：B（漫游性能核心指標是切換延遲，直接影響業(yè)務(wù)連續(xù)性）3.以下哪項不是網(wǎng)絡(luò)基線的作用？（）A.識別異常流量模式B.驗證優(yōu)化措施效果C.替代實時監(jiān)控工具D.定位性能瓶頸答案：C（基線用于對比分析，不能替代實時監(jiān)控）4.某校園網(wǎng)部署了IPv6，部分用戶反饋無法訪問IPv6-only的教育網(wǎng)資源。使用`ping6`測試顯示目標不可達，`traceroute6`在第三跳停止響應(yīng)。可能的故障點是（）A.用戶終端未啟用IPv6協(xié)議棧B.第三跳路由器未配置IPv6路由C.目標服務(wù)器防火墻攔截ICMPv6D.用戶終端DNS服務(wù)器不支持AAAA記錄答案：B（traceroute在中間跳停止，通常是路由缺失或跳數(shù)限制）5.測試OLT（光線路終端）到ONU（光網(wǎng)絡(luò)單元）的光衰時，發(fā)現(xiàn)接收光功率為-30dBm（OLT發(fā)光功率為+2dBm，光纖衰減系數(shù)0.3dB/km，熔接點損耗0.5dB/個，線路長度10km）?？赡艿漠惓Ｔ蚴牵ǎ〢.光纖長度計算錯誤（實際15km）B.ONU光模塊靈敏度不足（最低-28dBm）C.熔接點數(shù)量過多（實際5個）D.OLT光模塊發(fā)射功率異常答案：B（理論光衰=10×0.3+熔接點×0.5=3+熔接點×0.5，若熔接點2個則總衰3+1=4dB，接收功率應(yīng)為+2-4=-2dBm，遠高于-30dBm，故為ONU接收靈敏度不足）6.使用`mtr`工具測試到目標主機的路徑時，發(fā)現(xiàn)某一跳的丟包率為100%，但后續(xù)跳的丟包率為0?？赡艿脑蚴牵ǎ〢.該跳路由器丟棄ICMP報文B.后續(xù)跳路由器開啟了ICMP反射C.目標主機防火墻攔截ICMPD.該跳路由器與后續(xù)跳之間鏈路中斷答案：A（丟包率100%但后續(xù)正常，通常是中間節(jié)點過濾ICMP）7.某企業(yè)采用靜態(tài)路由實現(xiàn)雙出口冗余，主鏈路故障切換后，部分用戶無法訪問原通過主鏈路訪問的網(wǎng)站。最可能的原因是（）A.備用鏈路帶寬不足B.備用鏈路的NAT地址池未覆蓋原地址C.網(wǎng)站服務(wù)器僅綁定主鏈路IPD.用戶終端ARP緩存未更新答案：B（靜態(tài)路由切換后，NAT轉(zhuǎn)換可能使用備用地址池，若網(wǎng)站僅允許主鏈路IP訪問則無法連通）8.測試5G用戶面（UPF）的端到端延遲時，應(yīng)優(yōu)先選擇的測試方法是（）A.在用戶終端使用`ping`測試B.通過核心網(wǎng)元之間的GTP-U報文時間戳計算C.在基站側(cè)抓包統(tǒng)計空口延遲D.使用第三方云監(jiān)控工具答案：B（5G用戶面延遲需精確到網(wǎng)元間交互，GTP-U報文時間戳更準確）9.某無線AP的SSID為“Corp”，用戶反饋連接后無法獲取IP地址。檢查AP配置發(fā)現(xiàn)DHCP服務(wù)已啟用，地址池為00-200/24。使用`dhcping`測試顯示AP未響應(yīng)DHCP請求?？赡艿墓收鲜牵ǎ〢.AP的DHCP地址池已耗盡B.用戶終端無線網(wǎng)卡驅(qū)動異常C.AP的無線接口未綁定DHCP服務(wù)D.交換機到AP的網(wǎng)線水晶頭松動答案：C（DHCP服務(wù)啟用但無響應(yīng)，可能是接口未綁定服務(wù)）10.分析網(wǎng)絡(luò)流量時，發(fā)現(xiàn)大量源端口為5353、目的端口為5353的UDP報文，協(xié)議為mDNS。最可能的場景是（）A.企業(yè)郵件服務(wù)器間通信B.物聯(lián)網(wǎng)設(shè)備自動發(fā)現(xiàn)C.視頻會議流量協(xié)商D.網(wǎng)絡(luò)攻擊中的端口掃描答案：B（mDNS用于局域網(wǎng)內(nèi)設(shè)備自動發(fā)現(xiàn)，常見于物聯(lián)網(wǎng)場景）11.測試SDN網(wǎng)絡(luò)的控制器性能時，關(guān)鍵指標不包括（）A.流表下發(fā)延遲B.南北向接口吞吐量C.控制器集群同步時間D.交換機轉(zhuǎn)發(fā)芯片處理能力答案：D（SDN控制器性能關(guān)注控制平面，交換機轉(zhuǎn)發(fā)屬數(shù)據(jù)平面）12.某三層交換機的G0/1端口狀態(tài)為“down/down”，`showinterfacestatus`顯示物理層正常?？赡艿墓收鲜牵ǎ〢.對端設(shè)備接口未啟用B.端口速率/雙工模式不匹配C.光纖模塊類型不兼容（多模/單模）D.接口帶寬被QoS限制答案：A（物理層正常但協(xié)議層down，通常是對端未啟用接口）13.排查VoIP通話雜音問題時，重點分析的QoS指標是（）A.吞吐量B.抖動C.丟包率D.B和C答案：D（VoIP對抖動和丟包敏感，需同時關(guān)注）14.使用`tc`工具模擬網(wǎng)絡(luò)延遲時，設(shè)置“delay100ms20ms25%”，表示（）A.平均延遲100ms，最大延遲20ms，25%概率無延遲B.平均延遲100ms，延遲變化±20ms，25%的報文延遲符合該分布C.固定延遲100ms，20%的報文額外延遲25msD.最小延遲100ms，最大延遲120ms，25%的報文延遲隨機答案：B（delay后參數(shù)為平均延遲、延遲偏差、偏差概率）15.某校園網(wǎng)出口路由器日志顯示大量“TCPSYNflood”告警，但流量監(jiān)控顯示總流量未超閾值?？赡艿脑蚴牵ǎ〢.路由器啟用了TCPSYNCookieB.攻擊流量被上游防火墻攔截C.路由器的會話表容量不足D.監(jiān)控工具采樣頻率過低答案：C（會話表滿時，即使總流量正常也會觸發(fā)SYNflood告警）二、填空題（每空1分，共20分）1.網(wǎng)絡(luò)測試的三層模型包括物理層測試、數(shù)據(jù)鏈路層測試和網(wǎng)絡(luò)層及以上測試。2.故障診斷的“OSI分層排查法”中，檢查網(wǎng)線是否正常屬于物理層，驗證IP地址配置屬于網(wǎng)絡(luò)層。3.Wireshark中過濾HTTPPOST請求的表達式是http.request.method=="POST"。4.衡量網(wǎng)絡(luò)可靠性的核心指標是MTBF（平均無故障時間）和MTTR（平均修復時間）。5.5GNR網(wǎng)絡(luò)中，用戶面延遲的理論最小值約為1ms（空口），控制面延遲需小于10ms。6.無線AP的“隱藏SSID”功能會導致關(guān)聯(lián)延遲增加，但無法完全阻止設(shè)備發(fā)現(xiàn)（可通過掃描空包檢測）。7.交換機的“環(huán)路檢測”功能通過提供樹協(xié)議（STP/RSTP）或BPDUGuard實現(xiàn)，防止廣播風暴。8.測試VPN連通性時，除檢查隧道建立狀態(tài)外，還需驗證內(nèi)部子網(wǎng)路由可達性和NAT穿越配置（若跨公網(wǎng)）。9.分析TCP重傳時，需區(qū)分快速重傳（基于重復ACK）和超時重傳（基于RTO超時）。10.網(wǎng)絡(luò)基線的建立需采集至少7天（覆蓋完整周周期）的流量、性能數(shù)據(jù)，包含峰值和谷值場景。三、簡答題（每題6分，共30分）1.簡述使用Wireshark分析TCP連接異常斷開的步驟。答案：①過濾TCP流量（tcp.port==目標端口）；②查找FIN或RST標志位報文；③檢查斷開方（客戶端/服務(wù)器）；④分析斷開前的報文序列（是否有重復ACK、超時重傳）；⑤結(jié)合時間戳判斷是正常關(guān)閉（FIN交換）還是異常終止（RST突然出現(xiàn)）；⑥關(guān)聯(lián)應(yīng)用層日志（如服務(wù)器崩潰、客戶端強制關(guān)閉）確認原因。2.對比“ping”和“nmap-sP”在網(wǎng)絡(luò)探測中的區(qū)別。答案：ping使用ICMPEchoRequest/Reply，僅能檢測響應(yīng)ICMP的主機；nmap-sP默認發(fā)送TCPSYN（80端口）、TCPACK（80端口）和ICMPEcho，可繞過僅過濾ICMP的設(shè)備；nmap能更全面發(fā)現(xiàn)存活主機（如屏蔽ICMP但開放端口的主機），而ping可能漏報。3.某企業(yè)Wi-Fi用戶反饋“連接后能打開HTTP網(wǎng)頁但無法訪問HTTPS”，請列出可能的故障點及排查方法。答案：可能故障點：①AP或AC的HTTPS端口（443）被ACL封禁；②無線VLAN的DHCP分配的DNS服務(wù)器異常（無法解析HTTPS站點的SSL證書域名）；③無線接入控制設(shè)備（如WLC）的TLS版本支持不足（與站點TLS1.3不兼容）；④用戶終端的SSL證書存儲異常。排查方法：①使用`telnet目標HTTPS站點443`測試端口連通性；②檢查無線VLAN的DNS配置（`nslookup`驗證解析）；③抓包查看HTTPS握手是否在ClientHello后中斷；④更換終端測試是否復現(xiàn)。4.簡述交換機端口“err-disable”狀態(tài)的常見原因及恢復方法。答案：常見原因：①環(huán)路檢測觸發(fā)（STP檢測到環(huán)路）；②雙工模式不匹配導致過多CRC錯誤；③端口安全違規(guī)（MAC地址超過限制）；④鏈路-flap（頻繁上下線）。恢復方法：①手動`shutdown`后`noshutdown`；②配置自動恢復（`errdisablerecoverycause<原因>interval<時間>`）；③排查根本原因（如移除環(huán)路、修復雙工配置、調(diào)整端口安全限制）。5.說明在40G以太網(wǎng)測試中，“背靠背幀測試”的目的及操作方法。答案：目的：驗證設(shè)備在無緩沖情況下處理突發(fā)流量的能力，評估緩存容量和轉(zhuǎn)發(fā)性能。操作方法：①測試儀表發(fā)送連續(xù)的最小幀（64字節(jié)）突發(fā)，長度為設(shè)備聲稱的最大緩存容量（如1000幀）；②逐步增加突發(fā)長度，直到設(shè)備出現(xiàn)丟包；③記錄不丟包的最大突發(fā)幀數(shù)，即為背靠背性能。四、分析題（每題10分，共20分）題目1：某企業(yè)總部（北京）與分公司（上海）通過MPLSVPN互聯(lián)，總部用戶反饋訪問上海分公司的ERP系統(tǒng)（IP：0）時延遲高達500ms（正常應(yīng)為50ms），但訪問互聯(lián)網(wǎng)正常。請設(shè)計排查步驟并定位可能的故障點。答案：排查步驟：1.確認用戶終端到總部出口路由器的延遲（`ping總部路由器IP`），排除終端到本地網(wǎng)絡(luò)問題。2.使用`traceroute0`定位延遲跳點：-若前幾跳（總部到MPLS入口PE）延遲正常，中間某跳（PE到對端PE）延遲突增，可能是MPLS鏈路擁塞或光纖故障。-若最后一跳（上海分公司內(nèi)網(wǎng)）延遲高，檢查分公司接入交換機到ERP服務(wù)器的鏈路（如端口速率、網(wǎng)線質(zhì)量）。3.檢查MPLSVPN的BGP路由（`showipbgpvpnv4`），確認是否存在路由繞行（如主鏈路故障后切換至備用長路徑）。4.抓取總部PE與上海PE之間的GRE/MPLS封裝流量，分析是否存在大量重傳（可能因鏈路誤碼率高）。5.登錄上海分公司ERP服務(wù)器，檢查CPU/內(nèi)存利用率（高負載會導致響應(yīng)延遲）?？赡芄收宵c：-MPLS骨干鏈路某段光纖衰耗過高（如熔接點老化），導致延遲增加；-BGP路由震蕩后切換至繞道路由（如原路徑為北京-上海直連，切換后經(jīng)廣州中轉(zhuǎn)）；-ERP服務(wù)器的網(wǎng)卡驅(qū)動異常（如接收隊列滿，導致處理延遲）。題目2：某商場部署了20臺Wi-Fi6AP（信道149/153/157），用戶反饋高峰期連接速度慢，且部分手機（如iPhone）頻繁斷開重連。通過AC管理界面查看，AP負載均衡正常（每AP連接30-40用戶），但丟包率達8%（正常＜2%）。請分析可能原因及解決措施。答案：可能原因：1.信道干擾：5GHz信道149/153/157屬DFS（動態(tài)頻率選擇）信道，若附近有雷達信號（如商場附近有氣象雷達），AP會強制切換信道，導致用戶斷連；2.終端能力差異：iPhone等設(shè)備對DFS信道的切換兼容性差，頻繁斷連；3.空口競爭：Wi-Fi6雖支持OFDMA，但高密場景下（每AP40用戶），上行資源單元（RU）分配不足，導致碰撞增加、丟包率上升；4.鄰區(qū)同頻干擾：AP覆蓋重疊區(qū)域存在同信道AP（如相鄰商場的AP使用相同信道），導致信號重疊干擾。解決措施：1.調(diào)整AP信道至非DFS信道（如36/40/44/48），避免雷達干擾；2.啟用AC的“DFS信道規(guī)避”功能，優(yōu)先選擇非DFS信道；3.優(yōu)化AP覆蓋（調(diào)整天線角度、降低發(fā)射功率），減少重疊區(qū)域；4.開啟Wi-Fi6的BSSColoring功能，區(qū)分同信道不同BSS的信號，降低干擾；5.部署5GHz160MHz頻寬（若終端支持），增加空口容量，減少用戶競爭。五、綜合應(yīng)用題（10分）某企業(yè)數(shù)據(jù)中心部署了SDN架構(gòu)（OpenFlow1.3），核心交換機（S1、S2）通過集群實現(xiàn)冗余，上聯(lián)至出口路由器（R1）。近期運維人員發(fā)現(xiàn)，部分虛擬機（VM1、VM2）跨核心交換機通信時延遲不穩(wěn)定（10-200ms），而同一核心交換機內(nèi)的VM通信正常。請設(shè)計完整的故障排查方案，包括工具、步驟及可能的故障點。答案：排查方案：1.確認流量路徑（工具：SDN控制器北向接口、`ovs-ofctldump-flows`）：-通過控制器查看VM1（IP0）到VM2（IP0）的流表路徑，確認是否跨S1和S2；-檢查流表匹配規(guī)則（如VLAN、IP五元組）是否正確，是否存在流表項丟失或錯誤。2.測試跨核心鏈路性能（工具：`iperf3`、`mtr`）：-在VM1和VM2間運行`iperf3-c`測試吞吐量和延遲；-使用`mtr--report-wide0`跟蹤路徑，確認延遲是否出現(xiàn)在S1-S2互聯(lián)鏈路；-若跨鏈路延遲高，檢查S1-S2間的物理鏈路（光纖/網(wǎng)線）是否存在誤碼（`showinterfacecounterserror`）。3.分析SDN控制器狀態(tài)（工具：控制器日志、`top`命令）：-檢查控制器集群同步狀態(tài)（如