先把三種錯誤放在不同層
設備出現重試時，先保留交換器埠計數、TCP重傳與應用請求紀錄。這三種事件可能相關，卻不是同一件事：乙太網路錯誤發生在鏈路，TCP可重傳遺失資料，應用則依自己的期限決定是否重送請求。不能看到十次CRC錯誤，就把十次業務重試全歸因於網路線。
先確認設備接在哪個實體埠、是否經過上行埠、聚合鏈路或閘道。保存交換器識別、埠名稱、介面索引與流量方向。輸入錯誤是從該埠收到資料的方向；交換器接設備的埠與接伺服器的埠，輸入方向相反，不能僅依名稱配對。
通用IF-MIB的ifInErrors代表輸入錯誤，ifInDiscards代表未因錯誤而無法交付、但被選擇丟棄的輸入封包；後者可能與資源有關。廠商畫面的CRC、FCS、alignment及discard欄位須再查型號手冊，不能把所有錯誤都當成CRC。
本篇適用於能取得管理統計的交換器及具有請求日誌的通訊服務。未指定交換器型號，因此不提供猜測的CLI命令或固定暫存器。你應先確認統計定義、計數寬度、重啟行為和讀取權限，再依本文方式建立對照表。
用兩次快照計算增加量
以教學假設建立六十秒觀察窗：10:00:00輸入錯誤120、輸入丟棄20；10:01:00分別132和20。差值是錯誤12、丟棄0，錯誤平均每秒0.2次。累積132不是這一分鐘發生132次，報告應同時保留起值、終值與時間間隔。
同一窗口應用共送一千個原始查詢，其中三個發生至少一次重試，共額外送出四次。受影響請求比例是3/1000=0.3%，額外嘗試相對原始請求為4/1000=0.4%。先定義分母，不能把這兩個百分比都叫重試率而不交代。
不要用12除1000宣稱封包錯誤率，因為一千是應用請求數，不是該介面的封包總數。取得合適的封包分母前，只報每秒錯誤增加量。若要算封包比例，要核對好包、錯包與丟棄是否互斥，以及計數是否涵蓋相同方向和層次。
計數變小時先查重啟、清零與計數不連續。IF-MIB可提供ifCounterDiscontinuityTime，另核對sysUpTime及設備識別。若重啟或不連續標記改變，這兩次快照不應直接相減；把窗口標示無效，重新建立起點。
已確認是連續運行且只有一次回繞的32位元計數，才可做模數差值。例如4294967290變為4，增加量是10。若取樣太慢可能多次回繞，這個公式無法還原真實總數；應縮短間隔或改用設備支援的較寬計數。
用時間窗口建立關聯
接著畫出每個觀察窗的錯誤增加量、TCP重傳量、應用逾時數與重試數。各系統時鐘若不同步，只能用較寬且註明誤差的窗口做相關分析，不能憑毫秒時間戳相近就斷定同一封包。保留收集時間及來源時間，避免把讀取延遲誤認為事件延遲。
案例中錯誤增加十二次，TCP仍可能靠重傳在應用期限前完成，因此只有三個查詢受影響並不矛盾。反過來，交換器錯誤不增加而應用逾時增加，也可能是設備處理慢、佇列阻塞、路由丟棄或觀察了錯的埠，不能宣稱網路完全正常。
若要進一步確認，針對測試查詢保留連線端點、請求識別、送出時間、完整回覆時間及TCP序列分析。交換器累積計數通常無法指出是哪個應用請求，必須靠更細的事件或適當位置的封包證據補足關聯。
接收端交換器埠的FCS錯誤增加，表示該接收點看到損壞訊框的線索；原因可能在傳送端、線材、接頭、干擾或該埠，不能直接指定某一條線必壞。把兩端介面與鏈路狀態一起記錄，再安排受控替換確認。
交換器自身丟棄的錯誤訊框未必會出現在一般鏡像抓包中，工具也可能不保留FCS。沒有在電腦抓到壞包並不能推翻埠計數；反之抓包工具報錯也須先排除擷取截短和網卡卸載造成的顯示差異。
做一次能重現的排查與驗收
先取得正常負載的基準，再選相同請求頻率、相同設備與相同持續時間重測。一次只變更一項，例如經維護流程更換可疑跳線，並保留更換前後的埠計數與負載。不要一口氣換線、換埠、改逾時，否則改善後仍不知道原因。
如果更換後三個連續六十秒窗口錯誤增加量皆為零，查詢期限通過率也恢復，可以記錄「在此負載與窗口未再觀察到問題」。這不是線材永遠不會故障的保證；驗收還需涵蓋現場必要的負載、運轉狀態與觀察時間。
失敗時先查資料是否有效：埠對不對、方向對不對、計數是否清零、時間是否跨重啟。再分別查鏈路錯誤、壅塞丟棄、TCP重傳及應用處理延遲。增加應用逾時可以減少表面重試，卻可能只把延遲藏起來，不能當成鏈路修復。
完成後應有一張可重算的紀錄：設備與埠、開始結束時間、起終計數、差值有效性、原始查詢數、受影響查詢數、額外嘗試數與變更項目。原始快照另存，讓下一位工程師確認百分比分母與窗口一致。
練習：下一窗口五百個原始查詢，兩個受影響、額外嘗試三次，埠錯誤由132變135。應得到錯誤增加3、受影響比例0.4%、額外嘗試比例0.6%。這些數字只能呈現共同窗口，尚未證明三個錯誤逐一造成三次重試。
常見問題與適用限制
問：交換器CRC增加一次，一定有一次應用失敗嗎？答：不一定。TCP重傳可能在期限前修復資料交付，應用未必失敗；UDP或其他協定的結果則依各自設計。
問：計數從大數變小，直接當零可以嗎？答：不行。先區分回繞、清零、重啟及介面更換；證據不足時標無法計算，重新取起點。
問：埠沒有錯誤，就可以排除網路嗎？答：不能。可能是丟棄、上游路徑、觀察點不對，或統計不支援。應搭配端點與回程證據。
問：何時可以說修復有效？答：在相同負載與驗收窗口下，相關指標和業務結果符合事先門檻，且保留前後資料；本文提供案例。
參考：RFC2863：IF-MIB介面錯誤、丟棄及計數不連續定義；具體硬體計數仍以廠商文件為準。
參考：RFC9293：TCP重傳與可靠傳輸背景，非應用重試策略。