Interpretieren von NextPort Disconnect-Ursachencodes

Einführung

In diesem Dokument wird beschrieben, wie die von den Cisco NextPort Digital Signal Processor (DSP)-Modulen gemeldeten Ursachencodes für Anrufe interpretiert werden. NextPort ist der DSP der nächsten Generation, der von Cisco für die Implementierung von Sprache, Daten oder Fax an einem bestimmten Port verwendet wird. Die Plattformen AS5350, AS5400, AS5850 und die neuen Modemkarten für AS5800 verwenden digitale Modems mit NextPort DSPs. Bei Digitalmodems in den Modellen C3600, AS5200, AS5300 und älteren Karten für AS5800 überprüfen Sie die Mikromodemzustände und Trennungsgründe: Kein Modem-Firmware-Upgrade kann NextPort DSP aus dem Mica DSP oder umgekehrt machen.

Voraussetzungen

Anforderungen

Dieses Dokument enthält keine spezifischen Anforderungen.

Hintergrundinformationen

Wenn ein Anruf mit den NextPort DSPs gelöscht oder getrennt wird, zeichnet das NextPort-Modul den Grund für die Verbindungstrennung auf. Mit diesem Trennungsgrund-Code kann bestimmt werden, ob die Verbindung normal getrennt wurde oder ein Fehler aufgetreten ist. Mit diesem Ursachencode können mögliche Fehlerquellen identifiziert werden. Modems können aufgrund verschiedener Faktoren getrennt werden, z. B. durch Client-Disconnects, Telco-Fehler und Anrufverluste auf dem Netzwerkzugriffsserver (NAS). Ein "guter" Trennungsgrund besteht darin, dass das DTE (Client-Modem oder NAS) am einen oder anderen Ende den Anruf beenden möchte. Solche "normalen" Unterbrechungen deuten darauf hin, dass die Trennung nicht auf Modem- oder Übertragungsebenenfehler zurückzuführen ist. Weitere Informationen zum Bestimmen, ob der Trennungsgrund "normal" ist, finden Sie unter Übersicht über die allgemeine Modem- und NAS-Leitungsqualität.

Hinweis: Der Trennungsgrund wird als "first-come-first-serve" verwaltet. Dies bedeutet, dass der erste Grund für die Trennung der Verbindung der einzige Grund ist, der gemeldet wurde. Wenn das Modem und das NAS versuchen, die Sitzung gleichzeitig zu beenden, und das Modem den Grund für die Trennung gespeichert hat, bevor die LINK_TERMINATE-Nachricht vom NAS verarbeitet wird, wird der Grund für die NAS-Trennung ignoriert.

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn sich Ihr Netzwerk in der Produktionsumgebung befindet, müssen Sie sich bei jedem Befehl zunächst dessen potenzielle Auswirkungen vor Augen führen.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps von Cisco zu Konventionen).

Bestimmen des Trennungsgrunds

Bei der Bewertung, ob Sie gute oder schlechte Verbindungen haben, ist es wichtig, die lange Geschichte der Verbindungsunterbrechungen zu erfassen, die ein bestimmter Port erlebt hat. In den meisten Umgebungen erfolgt die Trennung über Modem-Anrufaufzeichnungen oder Syslog-Meldungen des Anrufverfolgungssystems. Dieser Trenncode kann dann mithilfe der in diesem Dokument bereitgestellten Tabelle interpretiert werden (oder überprüfen Sie, ob Modemanalysetools verfügbar sind). Bestimmen Sie mithilfe der folgenden Befehle den Trennungsgrund:

• Der Befehl show spe modem disconnect-reason zeigt den Trennungsgrund-Code nicht als Hexadezimalwert an. Der Trennungsgrund wird jedoch als Name angegeben. Der Name und die Klasse des Trennungsgrundsatzes finden Sie in bzw..

• Der Befehl show port modem log zeigt den Disconnect Reason Code als Hexadezimalwert an. Siehe :

0x0.		0 x 001	0 x 002	0 x 003	0 x 004	0 x 005	0 x 006	0 x 007	0 x 008	0 x 009	0 x 00 C	0 x 00 D	0 x 00 E	0 x 00 F
	0 x 010	0 x 011	0 x 012
0x1..	0 x 100	0 x 101	0x102	0 x 103	0 x 104	0 x 105	0 x 106	0 x 107	0 x 108	0 x 109
	0 x 1 F00	0 x 1 F01	0 x 1 F02	0 x 1 F03	0 x 1 F04	0 x 1 F05	0 x 1 F06	0 x 1 F07	0 x 1 F08
														0 x 1 FFF
0x2		0 x 201	0 x 202	0 x 203	0 x 204	0 x 205	0 x 206
	0 x 210	0 x 211	0 x 212
	0 x 220	0 x 221	0 x 222		0 x 224	0 x 225
0x3..	0x3xx
0x4..		0 x 401		0 x 403	0 x 404				0 x 408
0x5..		0 x 501	0 x 502	0 x 503	0 x 504	0 x 505	0 x 506
														0 x 5 FF

Im nächsten Abschnitt werden einige Beispiele behandelt.

Verwenden des Protokollbefehls "show port modem"

Verwenden Sie den Befehl show port modem log slot/port (Steckplatz/Port anzeigen), um den Trennungsursachencode (in Hex) für einen bestimmten Anruf an einem bestimmten Port abzurufen. Dieser Trenncode ist identisch mit dem Ursachencode, der aus den Syslog-Ausgaben für Modemanrufe und Anrufnachverfolgung abgerufen wird. Ein Beispiel wird angezeigt:

*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

Beachten Sie im obigen Beispiel, dass der Trennungscode 0x220 lautet.

Befehl show spe modem disconnect-reason

Verwenden Sie den Befehl show spe modem disconnect-reason {summary | Steckplatz | steckplatz/spe}-Befehl, um die Verteilung von Trennungsgründen zu bestimmen, die bei dem jeweiligen Port aufgetreten sind. Nachfolgend finden Sie eine Beispielzusammenfassung für die Ausgabe aller Ports:

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

Nehmen wir an dem obigen Beispiel teil, dass wir an der Disconnect-Kategorie "Disk" in CLASS EC LCL interessiert sind. Um zu bestimmen, was der Trennungsgrund für Disk bedeutet, gehen Sie zum Eintrag für die Klasse (CLASS EC LCL ) und den Namen des Trennungsgrunds (Disk), der den Hexadezimalcode 0x220 anzeigt und eine normale Trennung darstellt.

• ANDERE KLASSE

• KLASSEN-DSP

• KLASSE EC LCL

• CLASS EC Cmd

• KLASSE EC FRMR

• KLASSE EC LD

• KLASSENHOST

Übersichtstabelle des NextPort Disconnect-Ursachencodes

Trennungsgrund - Typ	Trennungsgrund: Name	Trennungsursachencode (Hex)	Beschreibung
ANDERE KLASSE
2	Software-RST	0 x 001	Die Cisco IOS®-Software hat den Anruf aus einem unbestimmten Grund (SOFTWARE_RESET) getrennt.
2	EG-Laufzeit	0 x 002	Layer-Terminierung mit Fehlerkorrektur (EC)
2	Ungültiger MNP5-Rx	0 x 003	Die Dekomprimierungsaufgabe Microcom Network Protocol 5 (MNP5) erhielt ein illegales Token im Datenstrom. Bei der Implementierung von Komprimierung, Dekomprimierung oder Fehlerkorrektur durch das Modem oder den Partner liegt möglicherweise ein logischer Fehler vor. (Es besteht auch die Möglichkeit eines vorübergehenden Line- oder RAM-Speicherfehlers.)
2	Schlechter V42B	0 x 004	Die V.42bis- oder V.44-Dekomprimierungsaufgabe erhielt ein illegales Token im Datenstrom. Möglicherweise liegt ein logischer Fehler vor, wenn das Modem oder der Partner eine Komprimierung, Dekomprimierung oder Fehlerkorrektur implementiert. (Es besteht auch die Möglichkeit eines vorübergehenden Line- oder RAM-Speicherfehlers.)
2	Falscher COP-Status	0 x 005	<reserviert>
6,7	ATH	0 x 006	ATH-Befehl vom lokalen Modem erkannt. Der Befehl "ATH" (Hangup) AT wird vom lokalen Modem (NextPort) erkannt. Beispielsweise löscht die IOS DTE-Schnittstelle nach einem Wählvorgang von IOS den Anruf (durch Übertragung eines In-Band-Befehls "ATH" AT), nachdem der Anruf verbunden wurde.
3	Abgebrochen	0 x 007	AT-Modus "any key" Abbruch des Wählbefehls Der AT-Wählbefehl wurde durch den Abbruchbefehl "any key" abgebrochen. Beispielsweise leitet das Host-Modem einen Anruf ein. Während der Verbindungsherstellung wird durch Drücken einer beliebigen Taste der AT-Wählbefehl abgebrochen.
3	Ton anschließen	0 x 008	Der Anruf dauerte zu lange, um die Verbindung abzuschließen. Beachten Sie, dass der S7-Timer (Warten auf den Carrier nach dem Wählen) für diese Trennung abgelaufen ist. Zu den Ursachen gehören: Schwierigkeiten bei der Auswahl (Verhandlung) eines Layer-I-Standards, Eine Kombination aus Layer-I- und Layer-II-Einrichtung dauert zu lange. Beispiele: Fehlerbehebungsverhandlungen dauern länger als eine Umschulung oder aufgrund von Bitfehlern, die eingeführt werden, wenn das Client-Modem versucht, eine Verbindung mit einer "aggressiven" Geschwindigkeit herzustellen (z. B. versucht der Client-Modem-Empfänger, eine Verbindung mit einer Geschwindigkeit herzustellen, die er nicht aufrechterhalten kann). Diese Trennung kann auch auftreten, wenn das Antwortmodem vom Kanal keinen Ton hörte (z. B. war der Ausgangspunkt kein Modem).
2	DSP zurücksetzen	0 x 009	DSP wurde zurückgesetzt (Befehl/intern/spontan). Der DSP im Host-Modem wurde vom Control Processor (CP) oder Signal Processor (SP) zurückgesetzt. Der CP setzt den DSP zurück, wenn keine E-Mail-Nachrichten vom CP zum SP bestätigt werden. Der SP setzt sich selbst zurück, wenn ein interner Inkonsistenzfehler auftritt.
4,6		0 x 00 C	Die Größe des V.42bis- oder V.44-Codeworts wurde überschritten.
4,6		0 x 00 D	V.42bis oder V.44 empfangenes Codewort, das dem nächsten leeren Wörterbucheintrag entspricht.
4,6		0 x 00 E	V.42bis oder V.44 erhalten ein Codewort, das größer ist als der nächste leere Wörterbucheintrag.
4,6		0 x 00 F	V.42bis oder V.44 erhielten reservierten Befehlscode.
4,6		0 x 010	Die Ordinalgröße V.42bis oder V.44 hat acht überschritten.
4,6		0 x 011	Fehler bei V.42bis- oder V.44-Aushandlung.
4,6		0 x 012	V.42bis- oder V.44-Komprimierungsfehler.

KLASSEN-DSP
		0 x 1 x xx	Von SPE gemeldete DSP-Bedingungen
4,5	Kein Carrier	0 x 100	Das SPE-Trägersignal geht verloren. NextPort erkannte ein Verwerfen des Client-Modem-Carriers. Der NextPort DSP hörte den Carrier für einen Zeitraum ab, der über dem in Register S10 angegebenen Wert liegt (Auflegen nach Carrier Loss). Dies könnte bedeuten, dass der Gesprächspfad weggegangen ist oder der Client die Übertragung beendet hat. Wenn ein Layer-II-Protokoll (V.42 und/oder V.42bis) in Kraft ist, ist eine solche Trennung ungewöhnlich. Häufige Ursachen sind, dass Benutzer den Anruf abbrechen, bevor eine Verbindung hergestellt wird. Vorsätzliches Wählen, abgebrochene Anrufe und Zeitüberschreitung von Client-Anwendungen, wenn die Verbindung von Anrufen zu lange dauert (aufgrund mehrerer Neuzüge während der Layer-1-Aushandlung). Der Zustand des Carriers kann auch im normalen Datenmodus auftreten, wenn der Client den Carrier abrupt verwirft. Die häufige Ursache hierfür ist eine nicht ausgehandelte oder "verschmutzte" Trennung vom Client-Modem (z. B. das Client-Modem verwirft lediglich das Trägersignal). Dies kann auftreten, wenn die Verbindung plötzlich getrennt wird (Netzwerkfehler) oder das Client-Modem den Anruf abgeschaltet hat. Dies kann auch bei "billigeren" Client-Modems auftreten, die die Clear-Down-Protokolle für Layer I und/oder Layer II in einem DTR-Dropdown-Menü nicht implementieren. Bei einer großen Anzahl von Client-Modems gilt dies als normale Trennung.
3	Kein ABT dtctd	0 x 101	Es wurde kein Freizeichenton erkannt - der Anrufer ist wahrscheinlich kein Modem.
3	Trainingsflrv	0x102	Anruffehler, während das Modem aufgrund inkompatibler Modulation oder schlechter Leitung trainiert. Dies kann ein Hinweis auf Versuche sein, eine nicht unterstützte Modulation wie eine proprietäre Legacy-Rockwell-Modulation (K56Plus, V.FC usw.) auszuhandeln. Weitere mögliche Ursachen sind DSP-Ausfälle bei der Zugeinrichtung aufgrund schwerer Leitungsstörungen, Impulsgeräusche, Unterbrechungsschulungen, inkompatible Modulationsparameter und möglicherweise die Unfähigkeit, einen Layer-I-Standard korrekt auszuwählen.
4,5	Retrain ln	0 x 103	Zu viele aufeinander folgende Züge oder Geschwindigkeitsverschiebungen. Der Umzugsgrenzwert wird mit Register S40 festgelegt. Während eines Anrufs kam es zu zu vielen Neuschulungen, die den Anruf unwirksam machten, da die Datenrate so schlecht war, dass sie nutzlos war. Weitere mögliche Bedingungen sind, dass das Client-Modem das Clear-Down-Protokoll nicht vollständig ausführt (z. B. das Telco-Gerät den Anruf in der Mitte der Verbindung abgeschaltet hat) und NextPort (NP) versucht, den Anruf durch Neuzuweisungen wiederherzustellen. Sobald die Umzugsgrenze erreicht ist, verwirft NP den Anruf und gibt den Grund für die Trennung bekannt.
3	ABT-Endknoten	0 x 104	Problem bei der Erkennung des Endes des Answer-Back Tone (ABT). Verhandlungsversagen oder übermäßiges Geräusch während der V.34-Ausbildung. Host-Modems antworten und senden V.8bis- und modulierte 2100Hz-Rückwärtstöne (ABTs) mit Phasenrückwandlern aus, treten jedoch während der Trainingssequenz auf ein lautes Geräusch. Suchen Sie auf Fehler im Pfad vom anrufenden Modem zum beantwortenden Modem in eine oder beide Richtungen. Ein ähnliches Verhalten tritt auf, wenn im öffentlichen Telefonnetz (PSTN) eine Latenz für die Einwahlverbindung besteht, die eine Sekunde überschreitet und dazu führt, dass die Modems die Echounterdrückung nicht trainieren können. Weitere mögliche Ursachen sind: Die tatsächlichen TX-Leistungsstufen sind falsch, und die Töne werden dann nicht von der Außenseite behandelt. Während der V.34-Ausbildung gibt es in den Phasen III und IV zu viel Rauschen. Es liegt ein Operatorfehler vor. Während der V.34-Schulung kommt es zu Netzwerkstörungen (jemand nimmt die Durchwahl an).
3		0 x 105	SS7/COT (Continuity Test) Operation erfolgreich abgeschlossen.
3		0 x 106	SS7/COT (Continuity Test)-Vorgang fehlgeschlagen: T8/T24-Timeout beim Warten auf "tone on" (Ein/Aus).
3		0 x 107	SS7/COT (Continuity Test)-Vorgang fehlgeschlagen: T8/T24-Timeout für "Ton aus".
4		0 x 108	Modem On Hold (MOH) wird durch NextPort deaktiviert. V.92 gibt an, dass der Grund für die Entfernung folgendermaßen lauten kann: Bereinigen aufgrund eines eingehenden Anrufs Bereinigen aufgrund eines ausgehenden Anrufs Löschen aus anderen Gründen
4		0 x 109	MOH-Timeout-Wert erreicht. Dieser Wert kann mit Register S62 (V.92 Maximale MoH-Zeit) angepasst werden.

KLASSE EC LCL: EG-Zustand, lokal erkannt
		0x2xx	Bedingungen für lokale Fehlerkorrektur (EC).
3	Kein LR	0 x 201	Während der Verhandlung wurde kein Link Request (LR) Frame empfangen. Peer unterstützt MNP möglicherweise nicht.
3	LR Param1	0 x 202	Der empfangene MNP-LR-Frame hatte einen fehlerhaften/unerwarteten PARAM1. Weitere Informationen zu PARAM1 finden Sie in der V.42-Spezifikation.
3	LR-Incentive	0 x 203	Der empfangene MNP LR-Frame ist nicht mit den EC-Einstellungen des Host-Modems kompatibel.
4,5	Rücklauf-LED	0 x 204	Zu viele aufeinander folgende Übertragungen in der EG. Dieser Trennungsgrund kann durch Geräusche auf der Leitung verursacht werden. Beispielsweise überträgt das Host-Modem Daten an das Client-Modem, aber Geräusche in der Leitung führen dazu, dass die Daten von der Client-Seite falsch (oder gar nicht) empfangen werden. Übermäßiges Geräusch kann also zu übermäßigen Neuübertragungen führen. Das Client-Modem hätte auch getrennt werden können, ohne dass das Host-Modem dies bemerkt. Das Host-Modem überträgt also kontinuierlich weiter, ohne zu wissen, dass das Client-Modem nicht mehr vorhanden ist. Wenn der Anruf in LAPM oder MNP verbunden wird, kann NextPort manchmal keinen Frame an das Client-Modem übertragen. Das Client-Modem bestätigt die erste Übertragung von NextPort nicht und reagiert dann nicht auf S19-Abfragen (Error Correction Retransmission Limit) (die Standardeinstellung ist 12), sodass NP den Anruf trennt. Eine Ursache könnte sein, dass der Carrier im Übertragungspfad erheblich heruntergefallen ist, während der Client nicht umschalten konnte. Eine andere Ursache könnte ein Problem mit der EC-Engine des Clients sein (wie es bei einem Winmodem-System der Fall wäre, wenn Windows nicht mehr reagiert).
6,7	Inaktivität	0 x 205	Timeout bei Inaktivität, LD (MNP Link Disconnect) gesendet. Das Host-Modem sendet dem Client-Modem einen LD-Frame, der anzeigt, dass ein Timeout bei Inaktivität aufgetreten ist.
4,5	Protokoll-Fehler	0 x 206	EC-Protokollfehler. Dies ist ein allgemeiner catch-all-Protokollfehler. Sie weist darauf hin, dass ein LAPM- oder MNP EC-Protokollfehler aufgetreten ist.
3	Fallback-Begriff	0 x 210	Es ist kein EC-Fallback-Protokoll verfügbar. Die Verhandlung zur Fehlerkorrektur wurde nicht erfolgreich durchgeführt. Der Anruf wird beendet, da kein Fallback-Protokoll zur Fehlerbehebung verfügbar ist. S-register S25 (Link Protocol Fallback) bestimmt das verfügbare Fallback-Protokoll. Die Optionen sind asynchrones Framing, synchrones Framing oder Disconnect (auflegen).
3	Kein XID	0 x 211	Sie haben während der Aushandlung nie den Frame eXchange IDentification (XID) erhalten. Peer unterstützt MNP möglicherweise nicht.
3	XID-Incentive	0 x 212	Der empfangene XID-Frame ist nicht mit den lokalen Einstellungen kompatibel. Das Client-Modem unterstützt LAPM unter V.42 möglicherweise nicht.
3,4,5	Festplatte	0 x 220	Empfänger Disconnect (DISK)-Frame. Dies ist die normale LAP-M-Trennung. Der Anruf wurde normal beendet, wobei der Client eine ordnungsgemäße, von der Client-Seite abgeschlossene Verbindung aufweist. (Beispielsweise wurde ein V.42-Trennpaket vom Client-Modem an das Host-Modem gesendet.) Das Client-Modem verließ DTR und handelte ein Clear-Down-Protokoll sauber aus.
3,4,5	DM	0 x 221	Empfangener DM-Frame. Peer trennt möglicherweise die Verbindung. Das Client-Modem zeigt an, dass die Verbindung getrennt wird. Während der Anrufeinrichtung deutet dies darauf hin, dass das Client-Modem die Aushandlung der Fehlerkorrektur aufgibt.
4,5	Schlechter NR	0 x 222	Ungültige Empfangs-Sequenznummer oder ACK-Nummer wurde empfangen. Ein MNP LD oder LAP-M FRMR wird gesendet. Das Host-Modem erhielt einen LAPM- oder MNP-Fehlerkorrektur-Frame mit einer falschen Sequenznummer oder Bestätigungsnummer. Ein LD- oder Frame Reject (FRMR)-Frame wird an das Client-Modem gesendet, um anzuzeigen, dass das Host-Modem die Verbindung trennt.
4,5	GLEICHZEITIG online	0 x 224	Empfangener MNP XID-Frame im Steady-State. Dies wird als LAPM-Fehlerkorrekturfehler im stationären Zustand interpretiert. Das bedeutet, dass das Client-Modem aufgrund des Empfangs eines FRMR zurückgesetzt wurde.
4,5	XID Online	0 x 225	Empfangs-MNP-LR-Frame im stationären Zustand. Dies wird als Fehler bei der MNP-Fehlerkorrektur im stationären Zustand interpretiert. Das bedeutet, dass das Client-Modem zurückgesetzt wurde.

CLASS EC Cmd: EC hat einen schlechten Befehlscode gefunden
4,5	Falsche CMD	0x3xx	EC hat einen ungültigen Befehlscode erkannt. Der empfangene unbekannte Befehl befindet sich in den letzten zwei Ziffern. Als Antwort wird ein MNP LD- oder LAP-M FRMR-Frame gesendet.

KLASSE EC FRMR: EG hat FRMR vom Peer erkannt
4,5		0x4xx	EC-Bedingungen, die vom Kunden im LAP-M FRMR-Frame angegeben werden. Der bitzugeordnete Grund befindet sich in den letzten zwei Ziffern.
4,5	Falsche CMD	0 x 401	LAPM: Peer meldet einen ungültigen Befehl. Das Host-Modem erhielt einen FRMR-Frame vom Client-Modem. Der erhaltene FRMR-Frame weist darauf hin, dass das Client-Modem einen Fehlerkorrekturrahmen vom Host-Modem erhalten hat, der einen fehlerhaften Befehl enthielt.
4,5	FRR-Daten	0 x 403	LAPM: Peer berichtet, dass Datenfelder nicht zugelassen sind oder eine falsche Länge aufweisen (U-Frames). Das Host-Modem erhielt einen FRMR-Frame vom Client-Modem. Der erhaltene FRMR-Frame gibt an, dass das Client-Modem einen Fehlerkorrekturrahmen vom Host-Modem erhalten hat, der ein Datenfeld enthielt, das nicht zulässig ist oder ein Datenfeld mit falscher Länge enthielt (d. h. U-Frame).
4,5	Länge des Formulars	0 x 404	LAPM: Die Länge des Datenfelds für Peer-Berichte ist größer als N401 (die in V.42 angegebene maximale Länge des Informationsfelds), verfügt aber über eine gute Frame Check Sequence (FCS). Das NextPort-Modem erhielt einen FRMR-Frame vom Client-Modem. Der empfangene FRMR-Frame gibt an, dass das Clientmodem einen Fehlerkorrekturrahmen von NextPort erhalten hat, der eine Datenfeldlänge enthält, die größer ist als die maximale Anzahl von Oktetten, die im Informationsfeld (N401) eines I-Frames, eines SREJ-Frames, eines XID-Frames, eines UI-Frames oder eines TEST-Frames übertragen werden können. Die Rahmenprüfsequenz ist gut.
4,5	Frame Bad NR	0 x 408	LAPM: Peer-Berichte erhalten eine ungültige Empfangssequenznummer oder N(R). Das Host-Modem erhielt einen FRMR-Frame vom Client-Modem. Der empfangene FRMR-Frame gibt an, dass das Client-Modem einen Fehlerkorrekturrahmen vom Host-Modem erhalten hat, der eine fehlerhafte Empfangssequenznummer enthielt.

KLASSE EC LD: Error Correction (EC) detected Link Disconnect (LD) from Peer
4,5		0x5xx	EC-Bedingungen, die vom Kunden im MNP LD Frame angegeben werden. Das Feld "Grund" befindet sich in den letzten 2 Ziffern.
3	LD kein LR	0 x 501	MNP: Peer hat nie LR-Frame empfangen. Das Host-Modem erhielt einen LD-Frame vom Client-Modem. Der empfangene LD-Frame zeigt an, dass das Client-Modem nie eine Verbindungsanforderung vom Host-Modem erhalten hat.
3	LD LR Param1	0 x 502	MNP: Peer Reports Link Request (LR) Frame hat fehlerhaften Parameter 1 Das Host-Modem erhielt einen Link Disconnect (LD)-Frame vom Client-Modem. Der empfangene LD-Frame gibt an, dass das Client-Modem einen Link-Request-Frame vom Host-Modem erhalten hat, der einen fehlerhaften (d. h. unerwarteten) PARAM1 enthielt. Weitere Informationen zu PARAM1 finden Sie in der V.42-Spezifikation.
3	LD LR-Incentive	0 x 503	MNP: Peer meldet, dass der LR-Frame nicht mit seiner Konfiguration kompatibel ist. Das Host-Modem erhielt einen LD-Frame (Link Disconnect) vom Client-Modem. Der empfangene LD-Frame gibt an, dass das Client-Modem einen Link Request (LR)-Frame vom Host-Modem erhalten hat, der nicht mit der Konfiguration des Client-Modems kompatibel ist.
4,5	LD-Rückrufe Lt	0 x 504	MNP: Peer-Berichte zu vielen aufeinander folgenden EC-Weiterleitungen Das Host-Modem erhielt einen LD-Frame vom Client-Modem. Der empfangene LD-Frame zeigt an, dass das Client-Modem zu viele aufeinander folgende Übertragungen erhalten hat.
4,5	LD-Inaktivität	0 x 505	MNP: Peer meldet Inaktivitäts-Timer abgelaufen Das Host-Modem erhielt einen LD-Frame (Link Disconnect) vom Client-Modem. Der empfangene LD-Frame gibt an, dass der Host des Client-Modems (DTE) innerhalb einer bestimmten Zeit keine Daten an das Client-Modem weitergegeben hat.
3	LD-Protokoll	0 x 506	MNP: Peer meldet Fehler Das Host-Modem hat vom Client-Modem einen LD-Frame empfangen. Der empfangene LD-Frame gibt an, dass das Client-Modem einen MNP-Protokollfehler erhalten hat.
3	LD-Benutzer	0 x 507	Normale MNP-Trennung Das Host-Modem erhielt einen LD-Frame vom Client-Modem. Der empfangene LD-Frame zeigt eine normale MNP-Terminierung an.

KLASSENHOST: Vom Host angefordert
6,7		0 x 1 Fxx	Vom Host initiierte Trennung Value ist eine Summe aus 0x1F00 und dem SessionStopCommand-Wert. Dies ist der Grund für die Beendigung des Hosts. Der Hostgrund wird in den Bytes "xx" mit niedriger Reihenfolge angegeben.
3,6,7	HST-Nicht-Spec	0 x 1 F00	Die Verbindung wurde vom unspezifischen Host initiiert. Value ist eine Summe aus 0x1F00 und dem SessionStopCommand-Wert. Dies ist der "catch all"-Grund, der von IOS initiiert wurde, um die Verbindung zu trennen. Sie wird für alle nicht standardmäßigen Verbindungen verwendet. Dies könnte beispielsweise darauf zurückzuführen sein, dass die Modemverwaltungssoftware beschließt, den Anruf zu beenden. Eine mögliche Erklärung ist ein Fehler bei der Authentifizierung auf höherer Ebene (RADIUS, TACACS) oder eine andere Anwendung, die dem Host-Modem einen DTR-Drop ausgibt. Dieser Trennungstyp wird nicht auf CSR angerechnet, wenn sich das Host-Modem im Datenmodus befindet.
3	HST besetzt	0 x 1 F01	Die gewählte Nummer war besetzt. Die Verbindung wurde getrennt, weil der Host anzeigt, dass die gewählte Nummer besetzt ist.
3	HST Keine Antwort	0 x 1 F02	Die gewählte Nummer wurde nicht beantwortet. Die Verbindung wurde getrennt, weil der Host angibt, dass die gewählte Nummer nicht geantwortet hat.
3,6,7	HST-DTR	0 x 1 F03	"Virtuelle" DTR wurde entfernt. Dieser Status wird von der "Umleitung des E/A-Ports" übernommen, die zurzeit das Modem verwendet. Die Verbindung wurde getrennt, weil der Host die "virtuelle" DTR-Leitung verworfen hat. Diese generische Trennungsursache wird von der Cisco IOS-Software initiiert. Beispiele hierfür sind Timeout im Leerlauf, empfangene PPP-LCP-TERMREQ, Authentifizierungsfehler, Telnet-Auflegen usw. Um den Grund für den Auflegen zu ermitteln, überprüfen Sie den "Radius"-Trennungsgrund im Terminlaufbefehl für den Modemaufruf oder in Authentication, Authorization, and Accounting (AAA).
6,7	HST-ATH	0 x 1 F04	Der Befehl "ATH" (hangup) wurde vom lokalen Host erkannt.
3	HST NoDialTn	0 x 1 F05	Kein Zugriff auf das Telco-Netzwerk. Die Verbindung wurde getrennt, weil der Host nicht auf das Netzwerk zugreifen konnte (z. B. ISDN).
3,4,5	HST-Carr	0 x 1 F06	Das Netzwerk hat die Verbindung unterbrochen. Hierbei handelt es sich um eine vom Client ausgelöste Trennung, bei der es sich nicht um eine anständige Anrufbeendigung handelt. Sie kann während der Anrufeinrichtung auftreten. Eine häufige Ursache ist, dass Benutzer von Windows 95 oder Windows 98, die DFÜ-Netzwerke (Dial Up Networking, DUN) verwenden, auf "Cancel" (Abbrechen) klicken, bevor der Anruf den konstanten Status erreicht. Ein weiterer häufiger Grund ist ein vom Kunden initiierter DTR-Ausfall vor dem Steady State. Im Datenmodus ist dies auch eine vom Client ausgelöste Trennung, bei der es sich nicht um eine anständige Anrufbeendigung handelt (d. h. eine "verschmutzte" Trennung). Eine sehr häufige Ursache sind Authentifizierungsfehler.
3		0 x 1 F07	NAS beendet SS7/COT Betrieb. Die Verbindung wurde getrennt, weil das NAS-Gerät den SS7/COT-Vorgang (Continuity Test) beendet hat.
3		0 x 1 F08	Der SS7/COT-Vorgang wurde vom Router wegen eines T8/T24-Timeouts abgebrochen.
-		0 x 1 FFF	UNERSUCHTE BEENDIGUNG. Der Host sendet diesen Trennungsgrund, wenn er eine nicht angeforderte Abschlussmeldung erhält.

Trennungstypen

Trennungstyp	Beschreibung
0	(nicht verwendet)
1 - 0x2 ...	(nicht verwendet)
2 - 0x4..	Andere Situationen
3 - 0x6..	Zustand während der Anrufeinrichtung
4 - 0x8..	Im Datenmodus. Rx (Leitung zu Host) Daten leeren OK
5 - 0 x A ...	Im Datenmodus. Rx-Datenflush (von Leitung zu Host) nicht in Ordnung (im Moment sollten Anwendungen sich nicht um "nicht OK" kümmern)
6 - 0 x C	Im Datenmodus. Tx (Host an Line) Daten leeren OK
7 - 0 x E ...	Im Datenmodus. Tx (Host to Line) Datenflush nicht in Ordnung (im Moment sollten Anwendungen sich nicht um "nicht OK" sorgen)

Zugehörige Informationen

• Vergleichen von NextPort SPE-Befehlen mit MICA-Modembefehlen
• Übersicht über die allgemeine Modem- und NAS-Leitungsqualität
• Seite "Technischer Support" aufrufen
• Technischer Support – Cisco Systems