解釋NextPort斷開原因代碼
目錄
簡介
本文檔介紹如何解釋Cisco NextPort通用數位訊號處理器(DSP)模組報告的呼叫斷開原因代碼。NextPort是Cisco用來在指定連線埠上實作語音、資料或傳真的下一代DSP。AS5350、AS5400、AS5850平台和用於AS5800的新型數據機卡都使用帶NextPort DSP的數字數據機。對於C3600、AS5200、AS5300及舊版AS5800卡中的數字數據機，請檢查Mica數據機狀態和斷開連線原因：數據機韌體升級不能使NextPort DSP從Mica DSP中退出，反之亦然。
必要條件
需求
本檔案沒有特定需求。
背景資訊
每當使用NextPort DSP的呼叫被清除或斷開時，NextPort模組都會記錄斷開的原因。此斷開原因代碼可用於確定斷開是正常斷開還是發生了錯誤。此原因代碼可用於跟蹤可能的故障源。數據機可能由於多種因素而斷開，例如客戶端斷開、電信錯誤和網路接入伺服器(NAS)上的呼叫中斷。「良好」斷開原因是一端DTE（客戶端數據機或NAS）或另一端DTE想要終止呼叫。這種「正常」斷開表示斷開不是數據機或傳輸級別錯誤的結果。有關確定斷開原因是否為「正常」的詳細資訊，請參閱一般數據機和NAS線路品質概述
注意：斷開原因以先到先得的方式進行管理。這意味著生成的第一個斷開原因是唯一記錄的斷開原因。如果數據機和NAS嘗試同時終止會話，並且數據機恰好在處理來自NAS的LINK_TERMINATE消息之前儲存斷開原因，則忽略NAS斷開原因。
採用元件
本文件所述內容不限於特定軟體和硬體版本。
本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您在即時網路中工作，請確保在使用任何命令之前瞭解其潛在影響。
慣例
如需文件慣例的詳細資訊，請參閱思科技術提示慣例。
確定斷開連線原因
評估斷開情況是好是壞時，獲取特定埠經歷的斷開歷史是很重要的。在大多數環境中，斷開原因通過使用數據機呼叫記錄或呼叫跟蹤器系統日誌消息獲取。然後可使用本文檔中提供的表格解釋此斷開連線代碼(或檢視有關調制解調 
器分析工具的)。 使用以下命令確定斷開連線原因：
-
show spe modem disconnect-reason命令不會將斷開原因代碼顯示為十六進位制值。但是，它會將斷開原因顯示為名稱。斷開原因的名稱和類可以分別在中和中找到。
-
show port modem log命令以十六進位制值顯示斷開連線原因代碼。請參閱：
| 0x0.. | 0x001 | 0x002 | 0x003 | 0x004 | 0x005 | 0x006 | 0x007 | 0x008 | 0x009 | 0x00C | 0x00D | 0x00E | 0x00F | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0x010 | 0x011 | 0x012 | ||||||||||||
| 0x1.. | 0x100 | 0x101 | 0x102 | 0x103 | 0x104 | 0x105 | 0x106 | 0x107 | 0x108 | 0x109 | ||||
| 0x1F00 | 0x1F01 | 0x1F02 | 0x1F03 | 0x1F04 | 0x1F05 | 0x1F06 | 0x1F07 | 0x1F08 | ||||||
| 0x1FFF | ||||||||||||||
| 0x2 | 0x201 | 0x202 | 0x203 | 0x204 | 0x205 | 0x206 | ||||||||
| 0x210 | 0x211 | 0x212 | ||||||||||||
| 0x220 | 0x221 | 0x222 | 0x224 | 0x225 | ||||||||||
| 0x3.. | 0x3xx | |||||||||||||
| 0x4.. | 0x401 | 0x403 | 0x404 | 0x408 | ||||||||||
| 0x5.. | 0x501 | 0x502 | 0x503 | 0x504 | 0x505 | 0x506 | ||||||||
| 0x5FF | ||||||||||||||
下一部分將檢視一些示例。
使用show port modem log命令
使用show port modem log slot/port 命令獲取特定連線埠上特定呼叫的結束通話原因代碼（十六進位制）。此斷開代碼與從數據機呼叫記錄和呼叫跟蹤器系統日誌輸出獲取的原因代碼相同。範例如下：
*Jan 1 00:53:56.867: Modem State event: State: Terminate
*Jan 1 00:53:56.879: Modem End Connect event:
Call Timer : 195 secs
Disconnect Reason Info : 0x220
Type (=0 ):
Class (=2 ): EC condition - locally detected
Reason (=32 ): received DISC frame -- normal LAPM termination
在上方範例中，請注意，結束通話代碼為0x220。
使用show spe modem disconnect-reason命令
使用show spe modem disconnect-reason {summary | slot | slot/spe}命令，確定特定埠經歷的斷開原因分佈。所有埠的摘要輸出示例如下所示：
NAS>show spe modem disconnect-reason summary
===CLASS OTHER==== =====CLASS DSP==== ===CLASS EC LCL=== ==CLASS EC FRMR===
Software Rst 0 No Carrier 341 No LR 0 Frmr Bad Cmd 0
EC Termntd 0 No ABT dtctd 0 LR Param1 0 Frmr Data 0
Bad MNP5 Rx 0 Trainup flr 328 LR Incmpt 0 Frmr Length 0
Bad V42B 110 Retrain Lt 0 Retrns Lt 226 Frmr Bad NR 0
Bad COP stat 0 ABT end flr 0 Inactivity 0
ATH 0 Protocol Err 1 ===CLASS EC LD====
Aborted 0 ====CLASS HOST==== Fallbck Term 74 LD No LR 0
Connect Tout 198 Hst NonSpec 0 No XID 67 LD LR Param1 0
Reset DSP 0 HST Busy 0 XID Incmpt 0 LD LR Incmpt 0
HST No answr 0 Disc 21448 LD Retrns Lt 0
===CLASS EC Cmd=== HST DTR 3615 DM 5 LD Inactivty 0
Bad Cmd 0 HST ATH 0 Bad NR 0 LD Protocol 0
HST NoDialTn 0 SABME Online 0 LD User 0
=====N O N E====== HST No Carr 5276 XID Online 0
None 39 HST Ack 0 LR Online 0 TOTAL 31728
HST NoDialTn 0 SABME Online 0 LD User 0=====N O N E======
HST No Carr 5276 XID Online 0 None 39 HST Ack 0
LR Online 0 TOTAL 31728
在上面的示例中，我們對CLASS EC LCL中的disconnect類別「Disk」感興趣。要確定Disk斷開原因意味著什麼，請轉到對應類(CLASS EC LCL)和斷開原因名稱(Disk)的條目，該條目顯示十六進位制代碼0x220並且是正常的斷開連線。
-
類別其他
-
DSP類
-
EC LCL類
-
EC類命令
-
EC FRMR類
-
EC LD類
-
類主機
NextPort斷開原因代碼摘要表
| 斷開連線原因型別 | 斷開連線原因：名稱 | 斷開連線原因代碼（十六進位制） | 說明 |
|---|---|---|---|
| 類別其他 | |||
| 2 | 軟體Rst | 0x001 | Cisco IOS®軟體由於某種不確定原因(SOFTWARE_RESET)而中斷了呼叫。 |
| 2 | EC終止 | 0x002 | 糾錯(EC)層終止 |
| 2 | 錯誤的MNP5 Rx | 0x003 | Microcom網路協定5(MNP5)解壓縮任務在資料流中收到非法令牌。數據機或合作夥伴執行壓縮、解壓縮或糾錯時可能存在邏輯錯誤。（也有可能出現瞬時線路或RAM記憶體錯誤。） |
| 2 | V42B故障 | 0x004 | V.42bis或V.44解壓縮任務在資料流中收到非法令牌。數據機或合作夥伴執行壓縮、解壓縮或糾錯時可能存在邏輯錯誤。（也有可能出現瞬時線路或RAM記憶體錯誤。） |
| 2 | COP狀態錯誤 | 0x005 | <保留> |
| 6,7 | ATH | 0x006 | 本地數據機檢測到ATH命令。本地數據機(NextPort)檢測到「ATH」（掛機）AT命令。 例如，在從IOS撥出後，在連線呼叫後，IOS DTE介面會清除該呼叫（通過傳送帶內「ATH」AT命令）。 |
| 3 | 已中止 | 0x007 | AT模式「any key」 abort of dial命令AT dial命令被「any key」 abort命令中止。例如，主機數據機發起呼叫。在建立連線期間，按「任何鍵」將導致AT撥號命令中止。 |
| 3 | Connect Tout | 0x008 | 呼叫花費的時間太長，無法完成連線。請注意，S7計時器（撥號後等待運營商）已過期，因此斷開連線。原因包括：
|
| 2 | 重置DSP | 0x009 | DSP已重置（命令/內部/自發）。 主機數據機中的DSP已由控制處理器(CP)或訊號處理器(SP)重置。 如果未確認從CP到SP的郵件，CP會重置DSP。SP如果收到內部不一致錯誤，則會重置自身。 |
| 4,6 | 0x00C | V.42bis或V.44碼字大小超過協商的最大值。 | |
| 4,6 | 0x00D | V.42bis或V.44接收的碼字等於下一個空字典條目。 | |
| 4,6 | 0x00E | V.42bis或V.44接收的碼字大於下一個空字典條目。 | |
| 4,6 | 0x00F | V.42bis或V.44收到保留的命令代碼。 | |
| 4,6 | 0x010 | V.42bis或V.44序號大小超過8個。 | |
| 4,6 | 0x011 | V.42bis或V.44協商錯誤。 | |
| 4,6 | 0x012 | V.42bis或V.44壓縮錯誤。 | |
| DSP類 | |||
|---|---|---|---|
| 0x1xx | SPE報告的DSP條件 | ||
| 4,5 | 無承運人 | 0x100 | SPE載波訊號丟失。NextPort檢測到客戶端數據機載波丟棄。NextPort DSP在大於暫存器S10中指定的值（載波丟失後的掛機延遲）的時間內停止偵聽載波。 這可能表示通話路徑已離開或客戶端停止傳輸。如果第II層協定（V.42和/或V.42bis）有效，則看到這種斷開是不正常的。常見的原因是使用者在建立連線之前「中止」呼叫。當呼叫連線時間過長時（由於在第1層協商期間多次重新訓練），意外撥號、中止啟動和客戶端應用程式超時。 在正常資料模式中，當客戶端突然丟棄載波時，也可能發生載波丟失情況。常見的原因是客戶端數據機部分未協商或「髒」斷開連線（例如，客戶端數據機僅丟棄載波訊號）。 如果鏈路突然斷開（網路錯誤），或者關閉客戶端數據機電源斷開呼叫，則可能發生這種情況。如果不在DTR丟棄上實施第I層和/或第II層清除協定的「更便宜」的客戶端數據機也會出現這種情況。對於大量客戶端數據機，這被視為正常斷開。 |
| 3 | 無ABT dtctd | 0x101 | 未檢測到回聲音 — 呼叫者可能不是數據機 |
| 3 | Trainup flrv | 0x102 | 由於調制不相容或線路錯誤，數據機培訓啟動時出現呼叫故障。這可能表示嘗試協商不受支援的調制，例如傳統Rockwell專有調制（K56Plus、V.FC等）。 其他可能的原因包括DSP由於嚴重的線路損傷、脈衝雜訊、中斷訓練、不相容的調制引數以及無法正確選擇第I層標準而無法進行訓練。 |
| 4,5 | 重新培訓Lt | 0x103 | 太多的連續再培訓或換班。暫存器S40指定了重新訓練限制。在呼叫過程中，發生了太多的重新訓練，導致呼叫無效，因為資料速率太差以致於沒有用處。其他可能的情況是，客戶端數據機沒有完成清除協定（例如，電信在連線中間中斷呼叫），NextPort(NP)嘗試通過發出重新訓練來恢復呼叫。一旦達到重新訓練限制，NP將放棄呼叫並報告此斷開原因。 |
| 3 | ABT結束過濾器 | 0x104 | 檢測迴音結束(ABT)時出現問題。 在V.34訓練期間協商失敗或噪音過大。主機資料機接聽並發出V.8bis和已調製的2100Hz應答迴音(ABT)，其相位反轉，但在訓練過程中遇到過多的雜訊。查詢從呼叫數據機到應答數據機的路徑中一個方向或兩個方向的錯誤。當用於撥號的公共交換電話網路(PSTN)中的延遲超過一秒並導致數據機無法訓練回聲消除器時，也會發生類似行為。其他可能的原因包括：
|
| 3 | 0x105 | SS7/COT（連續性測試）操作已成功完成。 | |
| 3 | 0x106 | SS7/COT（連續性測試）操作失敗：等待「tone on」的T8/T24超時。 | |
| 3 | 0x107 | SS7/COT（連續性測試）操作失敗：T8/T24等待「tone off」超時。 | |
| 4 | 0x108 | NextPort已清除資料機插撥(MOH)。V.92指定清除原因可以是：
|
|
| 4 | 0x109 | 已達到MOH超時值。此值可以使用寄存器S62(V.92 Maximum MOH time)進行調整。 | |
| EC LCL類：EC條件，本地檢測到 | |||
|---|---|---|---|
| 0x2xx | 本地糾錯(EC)條件。 | ||
| 3 | 無LR | 0x201 | 在交涉期間，未收到連結請求(LR)訊框。對等體可能不支援MNP。 |
| 3 | LR引數1 | 0x202 | 收到的MNP LR幀具有錯誤/意外的PARAM1。有關PARAM1的詳細資訊，請參閱V.42規範。 |
| 3 | LR輸入 | 0x203 | 收到的MNP LR幀與EC的主機數據機設定不相容。 |
| 4,5 | 返回Lt | 0x204 | EC中的連續重新傳輸過多。此斷開原因可能是線路上的噪音引起的。例如，主機數據機向客戶端數據機傳輸資料，但是線路上的噪音會導致客戶端錯誤地接收資料（或者根本不接收）。因此，過多的噪音會導致過多的重新傳輸。如果主機數據機沒有意識到這一點，客戶端數據機也可能已斷開連線。因此，主機數據機不斷重新傳輸，而不知道客戶端數據機不再存在。有時，當呼叫在LAPM或MNP中連線時，NextPort無法將幀傳輸到客戶端數據機。客戶端數據機無法確認NextPort的初始傳輸，然後無法響應Register S19（糾錯重傳限制）輪詢（預設值為12），因此NP斷開呼叫。一個原因可能是傳輸路徑中的載波在客戶端無法降頻時大幅度降級。另一個原因可能是客戶端的EC引擎有問題（如果Windows停止響應，在Winmodem系統上會發生這種情況）。 |
| 6,7 | 不活動 | 0x205 | 非活動超時，已傳送MNP鏈路斷開連線(LD)。主機數據機向客戶端數據機傳送一個LD幀，指示已發生非活動超時。 |
| 4,5 | 通訊協定錯誤 | 0x206 | EC協定錯誤。這是一般捕獲所有協定錯誤。它表示發生了LAPM或MNP EC協定錯誤。 |
| 3 | 備用術語 | 0x210 | 沒有可用的EC回退協定。糾錯協商未成功。由於沒有可用的糾錯回退協定，呼叫被終止。S-register S25（鏈路協定回退）確定可用的回退協定。選項包括非同步成幀、同步成幀或斷開連線（掛斷）。 |
| 3 | 無XID | 0x211 | 在協商期間從未收到交換ID標識(XID)幀。對等體可能不支援MNP。 |
| 3 | XID輸入 | 0x212 | 收到的XID幀與本地設定不相容。在V.42中，客戶端數據機可能不支援LAPM。 |
| 3,4,5 | 磁碟 | 0x220 | 已收到斷開連線（磁碟）幀。這是正常的LAP-M斷開連線。呼叫正常終止，從客戶端正確清除。（例如，V.42斷開連線資料包從客戶端數據機傳送到主機數據機）。 客戶端數據機丟棄DTR並乾淨地協商清除協定。 |
| 3,4,5 | DM | 0x221 | 已收到DM幀。對等體可能正在斷開連線。客戶端數據機指示正在斷開連線。在呼叫建立過程中，此原因表示客戶端數據機放棄協商糾錯。 |
| 4,5 | 錯誤NR | 0x222 | 收到錯誤的接收序列號或ACK號。傳送MNP LD或LAP-M FRMR。主機數據機收到一個序列號或確認號錯誤的LAPM或MNP糾錯幀。向客戶端數據機傳送LD或幀拒絕(FRMR)幀，指示主機數據機正在斷開連線。 |
| 4,5 | SABME Online | 0x224 | 收到處於穩態的MNP XID幀。這被視為穩態下的LAPM糾錯協定錯誤。這意味著客戶端數據機可能由於收到FRMR而重置。 |
| 4,5 | XID聯機 | 0x225 | 在穩態時收到MNP LR幀。這被解釋為穩態下MNP糾錯協定錯誤。表示使用者端資料機已重設。 |
| EC類命令：EC檢測到錯誤的命令代碼 | |||
|---|---|---|---|
| 4,5 | 錯誤命令 | 0x3xx | EC檢測到錯誤的命令代碼。收到的unknown命令位於最後2位。作為響應，傳送MNP LD或LAP-M FRMR幀。 |
| EC FRMR類：EC檢測到來自對等體的FRMR | |||
|---|---|---|---|
| 4,5 | 0x4xx | 客戶端在LAP-M FRMR幀中指示的EC條件。位對映的原因位於最後兩位數中。 | |
| 4,5 | Frmr Bad Cmd | 0x401 | LAPM:對等體報告錯誤的命令。主機數據機從客戶端數據機接收到FRMR幀。接收到的FRMR幀表示客戶端數據機從主機數據機接收到包含錯誤命令的糾錯幀。 |
| 4,5 | Frmr資料 | 0x403 | LAPM:對等體報告資料欄位不允許或不正確的長度（U幀）。 主機數據機從客戶端數據機接收到FRMR幀。所接收的FRMR幀指示客戶端數據機從主機數據機接收糾錯幀，該幀包含不允許的資料欄位或包含具有不正確長度（即，U幀）的資料欄位。 |
| 4,5 | 幀長度 | 0x404 | LAPM:對等體報告資料欄位長度大於N401（在V.42中指定的最大資訊欄位長度），但具有良好幀校驗序列(FCS)。 NextPort數據機從客戶端數據機接收到FRMR幀。所接收的FRMR幀指示客戶端數據機從NextPort接收到糾錯幀，該糾錯幀包含的資料欄位長度大於I幀的資訊欄位(N401)中可攜帶的最大八位數、SREJ幀、XID幀、UI幀或TEST幀。幀校驗序列良好。 |
| 4,5 | Frmr Bad NR | 0x408 | LAPM:對等體報告錯誤的接收序列號或N(R)。 主機數據機從客戶端數據機接收到FRMR幀。接收到的FRMR幀指示客戶端數據機從主機數據機接收到包含錯誤接收序列號的糾錯幀。 |
| EC LD類：錯誤更正(EC)檢測到對等裝置的鏈路斷開連線(LD) | |||
|---|---|---|---|
| 4,5 | 0x5xx | 客戶端在MNP LD幀中指示的EC條件。Reason欄位位於最後2位 | |
| 3 | LD否LR | 0x501 | MNP:對等體從未收到LR幀。主機數據機從客戶端數據機接收了一個LD幀。收到的LD幀表示客戶端數據機從未收到來自主機數據機的鏈路請求。 |
| 3 | LD LR引數1 | 0x502 | MNP:對等體報告連結請求(LR)訊框的引數錯誤#1：主機資料機從使用者端資料機收到連結結束連線(LD)訊框。收到的LD幀表示客戶端數據機從主機數據機收到包含錯誤（即意外的）PARAM1的鏈路請求幀。有關PARAM1的更多資訊，請參閱V.42規範。 |
| 3 | LD LR輸入 | 0x503 | MNP:對等體報告LR幀與其配置不相容主機數據機從客戶端數據機接收到鏈路斷開連線(LD)幀。收到的LD幀表示客戶端數據機從主機數據機接收到與客戶端數據機的配置不相容的鏈路請求(LR)幀。 |
| 4,5 | LD返回Lt | 0x504 | MNP:對等體報告過多連續EC重新傳輸主機數據機從客戶端數據機接收了一個LD幀。收到的LD幀表示客戶端數據機收到了過多的連續重新傳輸。 |
| 4,5 | LD不活動 | 0x505 | MNP:對等體報告非活動計時器過期主機數據機從客戶端數據機收到鏈路斷開連線(LD)幀。收到的LD幀表示客戶端數據機的主機(DTE)在一段時間內未向客戶端數據機傳遞資料。 |
| 3 | LD通訊協定 | 0x506 | MNP:peer reports error主機數據機從客戶端數據機接收到LD幀。收到的LD幀指示客戶端數據機收到MNP協定錯誤。 |
| 3 | LD使用者 | 0x507 | 正常MNP斷開連線主機數據機從客戶端數據機接收到LD幀。收到的LD幀指示正常的MNP終止。 |
| 類主機：由主機請求 | |||
|---|---|---|---|
| 6,7 | 0x1Fxx | 主機已啟動斷開連線。值是0x1F00和SessionStopCommand值的總和。這是另一個主機終止原因。主機原因以低位位元組「xx」表示。 | |
| 3,6,7 | HST非規格 | 0x1F00 | 非特定主機發起斷開連線。值是0x1F00和SessionStopCommand值的總和。這是「捕獲所有」IOS啟動的斷開原因。它用於所有非標準斷開。例如，這可能是數據機管理軟體決定終止呼叫的結果。一個可能的解釋是較高級別的身份驗證故障RADIUS、TACACS或另一個向主機數據機發出DTR丟棄的應用程式。當主機數據機處於資料模式時，這種型別的斷開連線不會計入CSR。 |
| 3 | HST忙 | 0x1F01 | 撥打的號碼正忙。已斷開連線，因為主機指示所撥號碼正忙。 |
| 3 | HST無響應 | 0x1F02 | 撥出的號碼沒有應答。已斷開連線，因為主機指示已撥號碼未應答。 |
| 3,6,7 | HST DTR | 0x1F03 | 「虛擬」DTR已丟棄。當前正在使用數據機的「I/O埠重定向器」會反映此狀態。已斷開連線，因為主機刪除了「虛擬」DTR線路。此通用斷開原因由Cisco IOS軟體啟動。例如，導致空閒超時、已接收PPP LCP TERMREQ、身份驗證失敗、Telnet掛斷等。要確定掛斷的原因，請通過modem call-record terse命令或身份驗證、授權和記帳(AAA)檢查「Radius」斷開原因。 |
| 6,7 | HST ATH | 0x1F04 | 本地主機檢測到「ATH」（掛機）命令。 |
| 3 | HST NoDialTn | 0x1F05 | 無法訪問電信網路。由於主機無法訪問網路（例如ISDN），因此已斷開連線。 |
| 3,4,5 | HST無卡 | 0x1F06 | 網路指示斷開連線。這是客戶端觸發的斷開連線，不是正常的呼叫終止。這可能發生在呼叫建立期間。一個常見的原因是使用Windows 95或Windows 98撥號網路(DUN)的使用者在呼叫達到穩定狀態之前按「取消」。另一個常見原因是任何客戶端都曾在穩定狀態前策動DTR下降。在資料模式期間，這也是客戶端觸發斷開連線，而不是平穩的呼叫終止（即「髒」斷開連線）。 一個非常常見的原因是身份驗證失敗。 |
| 3 | 0x1F07 | NAS終止了SS7/COT操作。由於NAS已終止SS7/COT（連續性測試）操作，因此出現斷開連線。 | |
| 3 | 0x1F08 | 由於T8/T24超時，路由器終止了SS7/COT操作。 | |
| - | 0x1FFF | 未經請求的終止。主機收到未經請求的終止消息時傳送此斷開連線原因。 | |
斷開連線原因型別
| 斷開型別 | 說明 |
|---|---|
| 0 | （未使用） |
| 1 - 0x2... | （未使用） |
| 2 - 0x4... | 其他情況 |
| 3 - 0x6... | 呼叫建立期間發生的情況 |
| 4 - 0x8... | 在資料模式下。Rx（線路到主機）資料刷新正常 |
| 5 - 0xA... | 在資料模式下。Rx（線到主機）資料刷新不正常（目前，應用程式不應擔心「不正常」） |
| 6 - 0xC... | 在資料模式下。Tx（主機到線路）資料刷新正常 |
| 7 - 0xE... | 在資料模式下。Tx（主機到線路）資料刷新不正常（目前，應用程式不應擔心「不正常」） |
意見