Die moderne analoge Modemkommunikation ist sehr komplex geworden. Die neuesten Technologien basieren nicht mehr auf einem einfachen Grundlayout, sondern erwarten, dass die Telco-Cloud auf digitaler Technologie durchgängig aufgebaut wird. Dies führte zu einer drastischen Erhöhung der Bandbreite auf Kosten der erhöhten Komplexität. Die Konnektivität der meisten Modemanrufe hängt jetzt von den Komponenten ab, die im folgenden Diagramm gezeigt werden:
Für dieses Dokument bestehen keine speziellen Anforderungen.
Dieses Dokument ist nicht auf bestimmte Software- und Hardwareversionen beschränkt.
Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.
Weitere Informationen zu Dokumentkonventionen finden Sie in den Cisco Technical Tips Conventions.
Lokale Schleifen bieten eine fehlerfreie Schnittstelle zur Telco Cloud. Ein Remote-Client kann entweder über eine analoge oder eine digitale Schleife verfügen, und Access-Server sind in der Regel für den Betrieb über eine digitale Schleife ausgelegt. Wenn eine der Schleifen ausfällt, schlägt auch die weitere Verbindung zwischen den Enden fehl.
Die Telco-Cloud überträgt die digitalen Signale transparent und durchgängig. Wenn eine Verbindung in der Mitte diese Anforderung nicht erfüllt (z. B. zusätzliche analoge zu digitale Konvertierungen, Kompressionen von Sprachkanälen, sporadische Datenverluste usw.), ist die Modem-Konnektivität wahrscheinlich beeinträchtigt, obwohl keine der beiden Endpunkte irgendetwas falsch an der Schleife erkennt.
Zusammenfassend lässt sich sagen, dass niedrige Erfolgsquoten bei Anrufen (Call Success Rate, CSR), schlechte Verbindungsgeschwindigkeiten, häufige Neuschulungen usw. nicht unbedingt Symptome eines schlechten Modemdesigns sind. Möglicherweise sind es nicht die Modems, die zuerst überprüft werden müssen.
In diesem Abschnitt werden häufige Probleme im Zusammenhang mit Modems aufgeführt und Informationen zur Behebung dieser Probleme bereitgestellt.
Manchmal melden Clients, die sowohl Modem (V.92, V.90, V.34) als auch digitale (ISDN, Switched 56, V.110 oder V.120) Anrufe tätigen, Verbindungsprobleme.
Wie bereits in der Einführung erläutert, werden Modemprotokolle zusätzlich zur Digitaltechnologie übertragen. Aufgrund ihrer Ursachen in fehleranfälliger analoger Kommunikation sind Modemprotokolle robuster und anpassungsfähiger für Leitungsfehler. Das Problem ist vielleicht nicht sehr auffällig, aber es besteht noch immer. Beheben Sie zunächst die Probleme bei digitalen Anrufen:
Überprüfen Sie die Controller- und Schnittstellenstatistiken, um sicherzustellen, dass die Leitung zwischen dem Zugriffsserver und dem nächsten Telco-Austausch fehlerfrei ist. Für Clients und Zugriffsserver, die Cisco Geräte verwenden, können Sie die Statistiken auf Controller- und Schnittstellenebene überprüfen. Befolgen Sie für Drittanbieterprodukte entweder die Herstellerdokumentation, oder Sie erhalten einen Protokollanalysator. Die Statistiken müssen auch auf der Telco-Seite überprüft werden (nur wenn sich das Problem nur auf die Signale auswirkt, die an den nächsten Telco-Austausch gesendet werden).
Wenn die Zähler sauber sind, die Leitung jedoch nicht direkt an der Telco-Börse terminiert wird (Zwischenzeilenerweiterungen oder -austausch sind beteiligt), überprüfen Sie den gesamten Pfad zum Telco-Austausch auf Fehler.
Wenn die Leitung als sauber bestätigt wurde, überprüfen Sie die Signalisierung. Informationen zu den Methoden zur Fehlerbehebung bei Channel Associate Signals (CAS) finden Sie unter Beheben von ISDN-Verbindungen.
Weitere Informationen finden Sie unter Übersicht über die allgemeine Modem- und NAS-Leitungsqualität.
Hinweis: Führen Sie alle diese Prüfungen durch, bevor Sie versuchen, eine Fehlerbehebung für das Modem durchzuführen.
Clients mit bestimmten Konten oder Clients, die von bestimmten Standorten aus anrufen, können keine Verbindung herstellen. Einige Modemmarken versuchen, eine Verbindung herzustellen, ohne dass zufriedenstellende Ergebnisse erzielt werden, während Clients an anderen Standorten anscheinend nicht betroffen sind.
Diese Probleme werden wahrscheinlich nicht durch Modems selbst verursacht. Konten (Rufnummern, Namen und Kennwörter) werden von Protokollen oder Anwendungen verwaltet, die sich neben Modemprotokollen (PPP, AAA, RPMS usw.) befinden. Möglicherweise ist es nicht hilfreich, das Modem bei der Fehlerbehebung zu unterstützen, wenn die Protokolle oder Anwendungen entfernt oder geändert werden müssen.
Versuchen Sie, mit der Fehlerbehebung fortzufahren:
Point to Point Protocol (PPP) Siehe DFÜ-Technologie: Fehlerbehebungsverfahren.
Authentifizierung, Autorisierung und Abrechnung (AAA).
Resource Pool Manager Server (RPMS).
Sofern keine speziellen Funktionen (wie die ID der anrufenden Nummer oder die angerufene Nummer) beteiligt sind, scheint das Problem irgendwo in der Telco-Cloud zu liegen. Wenn Sie dasselbe Modem an einem anderen Standort aufstellen, ändert sich nur ein Faktor: den Anrufpfad. Wenn die Änderung ausreicht, um das Problem zu beheben, sind die Endpunkte korrekt konfiguriert, und Sie müssen möglicherweise keine weitere Fehlerbehebung durchführen. Die Telco-Leitung zwischen dem Access-Server und der nächsten Telco-Exchange ist vermutlich in Ordnung, da nur bestimmte Clients das Problem haben. Eine mögliche Problemumgehung besteht darin, Modemeinstellungen zu finden, die den Modems trotz der Telco-Probleme die Verbindung ermöglichen würden. Weitere Informationen finden Sie unter Modems für die Feineinstellung.
Hinweis: Diese Problemumgehung ist keine Lösung. Um eine Lösung zu finden, wenden Sie sich an Ihren Telco, um die Leitung zwischen dem Kunden und der nächsten Telco-Börse und weiter entlang des Anrufpfads zu ermitteln.
Gelegentlich berichten Clients an bestimmten Standorten von unzureichender Konnektivität. Dazu gehören niedrige Verbindungsgeschwindigkeiten, häufig Neuzüge, hohe Fehlerquoten usw. Einige Modemmarken versuchen, eine Verbindung herzustellen, ohne dass zufriedenstellende Ergebnisse erzielt werden, während andere Standorte anscheinend nicht betroffen sind.
Sofern keine speziellen Funktionen (wie die ID der anrufenden Nummer oder die angerufene Nummer für das RPMS) beteiligt sind, scheint das Problem irgendwo in der Telco-Cloud zu liegen. Wenn Sie dasselbe Modem an einem anderen Standort verwenden, ändert sich nur ein Faktor: den Anrufpfad (innerhalb der Telco-Cloud können die Pfade für eingehende und ausgehende Anrufe variieren). Wenn die Änderung ausreicht, um das Problem zu beheben, sind die Endpunkte korrekt konfiguriert, und Sie müssen möglicherweise keine weitere Fehlerbehebung durchführen. Die Telco-Leitung zwischen dem Access-Server und der nächsten Telco-Exchange ist vermutlich in Ordnung, da nur bestimmte Standorte das Problem haben. Das Problem besteht höchstwahrscheinlich bei der Telco-Börse, die dem Kunden am nächsten liegt. Überprüfen Sie, ob die betreffenden Anrufe, wie unter Dialup Technology erläutert, überhaupt am Zugriffsserver eintreffen: Fehlerbehebungsverfahren.
Wenn der Anruf durchgestellt wird und die Telco-Leitung zwischen dem Client und der nächsten Telefonzentrale ebenfalls anscheinend sauber ist (z. B. wenn der Client das Problem nicht sieht, wenn er andere lokale Nummern anruft, wie z. B. das San-Jose Dial-in Lab oder das Australia Dial-in Lab), müssen Sie möglicherweise den gesamten Anrufpfad überprüfen, um weitere Fehler zu beheben.
So überprüfen Sie den Anrufpfad:
Prüfen Sie zunächst die interne Verkabelung als mögliche Problemursache.
Schließen Sie zwei Client-Modems wieder an die Kabelverbindung an (ATX3D wird verwendet, um ein Modem anzurufen, ohne auf den Wählton zu warten, und um das andere Modem zu antworten, ohne auf die Verwendung des ATA zu warten). Nachdem die Modems in den Datenmodus gewechselt sind, erzeugen Sie einen Teil des Datenverkehrs über die Strecke. Verwenden Sie dann die Escape-Sequenz (normalerweise Hayes ++ oder TIES +++AT), um die Modems in den Befehlsmodus umzuschalten, und überprüfen Sie die Leitungsparameter (Signal-Rausch-Verhältnis [SNR], Signalqualität, Neuzüge usw.).
Trennen Sie alle Geräte, die parallel zum Modem an dieselbe Telefonleitung angeschlossen sind.
Führen Sie ein Telefonkabel (vorzugsweise Quad oder Unshielded Twisted Pair [UTP]) von der Netzwerkschnittstelle direkt zum Modem aus.
Stellen Sie sicher, dass das Client-Modem die neueste Firmware vom Hersteller ausführt (in Übereinstimmung mit den Protokollen, die das Servermodem unterstützt). Überprüfen Sie außerdem, ob Sie das Client-Modem neu konfigurieren möchten, damit es robuster verbunden werden kann. Weitere Informationen finden Sie unter Fine-Tuning-Modems. Sie können beispielsweise versuchen, die DCE-Geschwindigkeit des Client-Modems zu begrenzen. Wenn es sich um einen Rockwell-Client handelt, versuchen Sie, AT+MS=56,1.300,42000 zu verwenden, um eine K56Flex-Verbindung mit 42 Kbit/s zu testen. Alternativ können Sie +MS=11,1,300,19200 für eine V.34-Verbindung mit 19,2 Kbit/s verwenden.
Aktivieren Sie die Modemprotokollierung auf dem Client für weitere Analysen.
Prüfen Sie bei mehreren A/D-Konvertierungen mit einem USR-Modem.
Wenn Sie Microsoft Windows verwenden, überprüfen Sie den Trennungscode .
Überprüfen Sie die Verbindungsdiagnose mit einem USR-Modem AT i11 oder einem Lucent-Modem AT i11 .
Wenn Sie ein von der CPU betriebenes Winmodem verwenden, fragen Sie den Modemhersteller nach dem vorhandenen AT-Befehl, um eine Verbindung zu beheben. Einige Modemanbieter verwenden den UnIModem-Diagnosecode von Microsoft (AT#UG).
Die Ermittlung des Anrufpfads kann eine engere Beteiligung Ihres Telco erfordern. Um potenzielle Probleme zu identifizieren, überprüfen Sie die Verbindungsparameter für bestimmte Anrufe mit dem Befehl show modem Operational Status (Betriebsstatus anzeigen des Modems), wie unter Übersicht über die allgemeine Modem- und NAS-Leitungsqualität beschrieben. Weitere Informationen finden Sie in diesem Versionshinweis. Eine mögliche Problemumgehung besteht darin, Modemeinstellungen zu finden, die es den Modems ermöglichen, sich selbst bei den Telco-Problemen zu verbinden. Siehe Modems zur Feineinstellung.
Auch wenn Clients an einigen Standorten eine Verbindung herstellen können, wird der Anruf später abgebrochen. Einige Modemmarken versuchen, eine Verbindung herzustellen, ohne dass zufriedenstellende Ergebnisse erzielt werden, während andere Standorte anscheinend nicht betroffen sind.
Sofern keine speziellen Funktionen (z. B. Rufnummer des Anrufers oder Angerufenen für RPMS) vorhanden sind, scheint das Problem irgendwo in der Telco-Cloud zu liegen. Wenn Sie dasselbe Modem an einem anderen Standort verwenden, ändert sich nur ein Faktor: den Anrufpfad (in der Telco-Cloud können sich die Pfade für eingehende und ausgehende Anrufe unterscheiden). Wenn die Änderung ausreicht, um das Problem zu beheben, ist der Zugriffsserver wahrscheinlich richtig konfiguriert und Sie müssen möglicherweise keine weitere Fehlerbehebung durchführen. Die Telco-Leitung zwischen dem Access-Server und der nächsten Telco-Exchange ist vermutlich ebenfalls in Ordnung, da nur bestimmte Standorte das Problem berühren. Um sicherzustellen, dass der DFÜ-Client nicht der Ursprung des Problems ist, überprüfen Sie Folgendes:
Der Client initiiert keine PPP-Trennung. Siehe DFÜ-Technologie: Fehlerbehebungsverfahren.
Der Client initiiert keine Modemtrennung. Die Gründe für die Trennung des Modems im Modemprotokoll werden in den folgenden Dokumenten erläutert:
Der Client initiiert keine ISDN-Trennung. Weitere Informationen finden Sie unter Ursache der ISDN-Trennung. (Siehe auch Hinweis 3.)
Wenn bei der Untersuchung festgestellt wird, dass die Anrufe aufgrund häufiger Verbindungsfehler getrennt werden, versuchen Sie, Modemeinstellungen zu finden, mit denen die Modems trotz der Telco-Probleme eine Verbindung herstellen können. Weitere Informationen finden Sie unter Modems für die Feineinstellung.
Hinweis: Diese Problemumgehung ist keine Lösung. Um eine Lösung zu finden, wenden Sie sich an Ihren Telco, um die Leitung zwischen dem Kunden und der nächsten Telco-Exchange und weiter entlang des Anrufpfads zu ermitteln.
Manche Modems können sich nicht verbinden, andere Modelle am selben Standort können das auch. Dies kann manchmal eine Frage der Anbieterkompatibilität sein. Um herauszufinden, warum genau die Verbindung getrennt wird, überprüfen Sie das Modem-Protokoll aus Gründen der Verbindungstrennung. (Siehe auch Hinweis 1):
Die mögliche Problemumgehung besteht darin, die Einstellungen zu identifizieren, mit denen Modems das Kompatibilitätsproblem vermeiden können. Weitere Informationen finden Sie unter Modems für die Feineinstellung. Wenn keine Problemumgehung hilft (z. B. die Deaktivierung aller proprietären Funktionen), wenden Sie sich an den Hersteller des Client-Modems, um weitere Fehlerbehebungen zu erhalten.
Stellen Sie sicher, dass Sie PPP entfernen. Das Client-Modem sollte über ein Terminalprogramm wie Windows HyperTerminal mit AT-Befehlen wählen. Konfigurieren Sie den Zugriffsserver so, dass PPP nicht automatisch für alle Benutzer gestartet wird, sondern dass eine EXEC-Anmeldung möglich ist (z. B. über den asynchronen Modus interaktiv auf der asynchronen Gruppenschnittstelle, und wählen Sie PPP auf den Leitungen automatisch aus). So kann der Client vom Modem aus direkt nützliche Informationen steuern und abrufen und nach der Verbindung exec-Datenverkehr generieren, um die Verbindung zu belasten.
Beginnen Sie auf dem Client-Terminal, die Sitzung zu protokollieren (wählen Sie Transfer > Capture Text in HyperTerminal).
Sammeln Sie folgende Informationen vom Client-Modem:
ATI, ATI0, ATI1, ATI2.
AT&V0, AT&V1, AT&V2.
Hinweis: Einige Befehle geben möglicherweise FEHLER auf einigen Modems zurück. Sie können solche Fehler ignorieren.
Setzen Sie das Modem auf die Werkseinstellungen (oder die anderen gewünschten Einstellungen) zurück, und stellen Sie sicher, dass der Lautsprecher immer eingeschaltet ist:
AT&F
ATL2M2
Zeichnen Sie den Anruf in eine WAV-Datei auf. Wählen Sie dazu unter Windows NT Start > Programme > Zubehör > Multimedia > Audiorecorder aus.
Die rote Taste startet die Aufzeichnung, aber drücken Sie sie erst, wenn Sie mit dem Wählen beginnen. Wählen Sie im Fenster HyperTerminal das gewünschte Gerät.
ATDT <Nummer>
Wenn der Anruf nicht verbunden wird oder die erforderliche Modulation nicht ausgehandelt wird, beenden Sie die Aufzeichnung, nachdem NO CARRIER im Terminalfenster angezeigt wird. Wenn das Problem darin besteht, dass sich der Anruf wie gewünscht verbindet, aber nach einiger Zeit nicht verbunden ist, notieren Sie die WAV-Datei. Wenn Sie Sound Recorder verwenden, müssen Sie jede Minute erneut die rote Aufzeichnungstaste drücken.
Wenn der Anruf eine Verbindung herstellt, entweder über die gewünschte oder eine unerwünschte Modulation, sammeln Sie während der Verbindung die folgenden interessanten Informationen.
auf Serverseite die Anzeige des Betriebsstatus des Modems (MICA, NextPort) oder des Modems im Modus / at@e1 (Microcom).
auf Client-Seite, gehen Sie durch +++ in den AT-Modus, und erhalten Sie ATI6, AT&V1, AT&V2. Sie können mit ATO wieder online gehen.
Wenn der Anruf beendet ist, speichern Sie die Audiorecorder-Datei. Wählen Sie dazu Datei > Speichern unter > Formatänderung.
Format: PCM
Attribute: 8,000 kHz, 8 Bit, Mono 7 kb/s
Dateiname: Dateiname.wav
Senden Sie die gesammelten Informationen zur Analyse an das Cisco Technical Assistance Center (TAC).
Bestimmte Modelle sind hinsichtlich niedriger Verbindungsgeschwindigkeiten, häufig Neuschulungen, hoher Fehlerquoten usw. nicht gut vernetzt. Andere Modelle an denselben Standorten verfügen über eine gute Anbindung.
Dies kann manchmal eine Frage der Anbieterkompatibilität sein. Um herauszufinden, warum genau die Verbindung getrennt wird, überprüfen Sie das Modem-Protokoll aus Gründen der Verbindungstrennung. (Siehe auch Hinweis 1):
Die folgende Untersuchung kann auch Aufschluss darüber geben, warum bestimmte Client-Modems fehlschlagen:
Prüfen Sie zunächst die interne Verkabelung als mögliche Problemursache.
Schließen Sie zwei Client-Modems wieder an die Kabelverbindung an (verwenden Sie ATX3D, um ein Modem anzurufen, ohne auf den Wählton zu warten, und um das andere Modem zu antworten, ohne auf das Klingelsignal zu warten. Verwenden Sie ATA). Nachdem die Modems in den Datenmodus eingezogen wurden, generieren Sie einen Teil des Datenverkehrs über die Strecke. Verwenden Sie dann die Escape-Sequenz (normalerweise Hayes ++ oder TIES +++AT), um die Modems in den Befehlsmodus umzuschalten, und überprüfen Sie die Leitungsparameter (SNR, Signalqualität, Neuzüge usw.).
Trennen Sie alle Geräte, die parallel zum Modem an dieselbe Telefonleitung angeschlossen sind.
Führen Sie ein Telefonkabel (vorzugsweise Quad oder UTP) von der Netzwerkschnittstelle direkt zum Modem aus.
Stellen Sie sicher, dass das Client-Modem die neueste Firmware vom Hersteller ausführt (in Übereinstimmung mit den Protokollen, die das Servermodem unterstützt). Konfigurieren Sie außerdem das Client-Modem neu, sodass eine robustere Verbindung hergestellt werden kann. Weitere Informationen finden Sie unter Modems für die Feineinstellung. Sie können beispielsweise versuchen, die DCE-Geschwindigkeit des Client-Modems zu begrenzen. Wenn es sich um einen Rockwell-Client handelt, versuchen Sie AT+MS=56,1.300,42000, eine K56Flex-Verbindung mit 42 Kbit/s herzustellen. Alternativ können Sie +MS=11,1,300,19200 für eine V.34-Verbindung mit 19,2 Kbit/s verwenden.
Aktivieren Sie die Modemprotokollierung auf dem Client für weitere Analysen.
Prüfen Sie bei mehreren A/D-Konvertierungen mit einem USR-Modem.
Wenn Sie Microsoft Windows verwenden, überprüfen Sie den Trennungscode .
Überprüfen Sie die Verbindungsdiagnose mit einem USR-Modem AT i11 oder einem Lucent-Modem AT i11 .
Wenn Sie ein von der CPU betriebenes Winmodem verwenden, fragen Sie den Modemhersteller nach dem vorhandenen AT-Befehl, um eine Verbindung zu beheben. Einige Modemanbieter verwenden den UnIModem-Diagnosecode von Microsoft (AT#UG).
Eine mögliche Problemumgehung besteht darin, die Einstellungen zu finden, wodurch die Modems das Kompatibilitätsproblem vermeiden können. Siehe Modems für die Feineinstellung. Wenn keine Problemumgehung hilft (z. B. die Deaktivierung von Neuschulungen auf internen Modems des Zugriffsservers), wenden Sie sich an den Hersteller des Client-Modems, um weitere Probleme zu beheben.
Einige Modems können eine Verbindung herstellen, aber später wird der Anruf beendet. Andere Modelle an denselben Standorten bleiben in Verbindung.
Dies kann manchmal eine Frage der Anbieterkompatibilität sein. Um herauszufinden, warum die Verbindung getrennt wird, überprüfen Sie Folgendes (siehe auch Hinweis 1):
Legt fest, ob eine PPP-Kündigung angefordert wurde. Siehe DFÜ-Technologie: Fehlerbehebungsverfahren.
Legt fest, ob eine Modemterminierung angefordert wurde. Die Modemtrennungsgründe im Modemprotokoll werden unter folgender Adresse erläutert:
ISDN Trennungsursache. (Siehe auch Hinweis 3).
Wenn bei der Untersuchung festgestellt wird, dass die Anrufe aufgrund von häufigen Verbindungsfehlern getrennt werden, besteht eine mögliche Lösung darin, die neueste Modemfirmware oder die neuesten Modemeinstellungen zu erhalten, sodass die Modems das Kompatibilitätsproblem vermeiden können. Weitere Informationen und eine Kompatibilitätsmatrix finden Sie unter Modems zur Feineinstellung. Wenn die Problemumgehung nicht hilfreich ist (z. B. die Begrenzung der maximalen Geschwindigkeit entweder manuell oder mithilfe einer aggressiven Modembegrenzung), wenden Sie sich an den Hersteller des Client-Modems, um weitere Probleme zu beheben.
Anrufe von verschiedenen Standorten mit verschiedenen Modemmodellen an bestimmte Nummern (DS1 oder Zugriffsserver) können nicht verbunden werden. Dieselben Clients an denselben Standorten verbinden sich mit anderen lokalen Nummern (z. B. San-Jose Dial-in Lab oder Australia Dial-in Lab).
Überprüfen Sie die Statistiken auf Controller- und Schnittstellenebene auf Fehler (weitere Informationen finden Sie in der Einführung). Wenn der Zugriffsserver beispielsweise mehr als eine Telco-Leitung terminiert, stellen Sie sicher, dass alle Leitungen synchronisiert sind (in der Regel bedeutet dies, dass die Leitungen vom gleichen Anbieter übernommen werden müssen), wie in der Uhrsynchronisierung erläutert. Die Überprüfung muss sowohl auf der Seite des Zugangs-Servers als auch auf der Seite des Telekoals erfolgen (wenn das Problem die Signale beeinflusst, die vom Zugangs-Server zur nächsten Telco-Exchange kommen, kann der Zugriffsserver keine Fehler melden). Bevor Sie mit der Fehlerbehebung für das Modem fortfahren, stellen Sie sicher, dass auf der T1/E1-Ebene praktisch keine Fehler auftreten.
Stellen Sie anschließend sicher, dass die Anrufe den Zugriffsserver erreichen, wie in der Dialup-Technologie erläutert: Fehlerbehebungsverfahren. Wenn die Anrufe eintreffen, aktivieren Sie den Befehl show controller <e1|t1> call-counter. Bei einigen Telco-Problemen melden bestimmte DS0-Kanäle in der Regel sehr niedrige Verbindungszeiten und eine sehr hohe Anzahl von Anrufen.
Für den letzten Test muss die Telco zulassen, dass sich der Zugriffsserver über die Telco-Exchange selbst aufruft. Stellen Sie außerdem sicher, dass der Pfad zwischen dem Access-Server und dem Switch keine externen analogen/digitalen Konvertierungen enthält. Dies erzeugt ein Nahecho, das digitale Modems möglicherweise nicht verarbeiten können, und verhindert, dass PCM-Modemverbindungen funktionieren. Wenn Sie eine T1- oder E1-Verbindung zum Telco bereitstellen, stellen Sie sicher, dass zwischen dem Access-Server und dem Telco-Switch ein rein digitaler Pfad vorhanden ist. Dies ist der Fall, wenn eine direkte T1- oder E1-Verbindung zum Switch besteht. Wenn beispielsweise die Kanäle über eine Kanalbank geroutet und damit von digital in analog und wieder zurück konvertiert werden, geht die digitale Integrität der Kanäle verloren. Das bedeutet:
Modemmodulation (Pulse Code Modulation, PCM) (V.90, K56Flex oder X2) kann nicht verwendet werden. Es können nur V.34 und weniger verwendet werden, und selbst V.34-Leistung kann beeinträchtigt werden.
Digitale Services wie Switched 56 oder ISDN-Daten können nicht bereitgestellt werden.
Digitale Modems wie MICA funktionieren aufgrund des hohen Niveaus von Nahecho nicht gut.
Typische Symptome bei MICA mit einer Nahauflösung-A-D-Umwandlung sind:
Kein PCM-Carrier (K56Flex oder V.90).
Mediocre (19,2 - 26,4) V.34 Carrier für Ortsgespräche.
Ferngespräche können nicht in V.34, V.32bis oder V.32 eingezogen werden. Wenn das Client-Modem jedoch auf 2400 bps V.22bis begrenzt ist, kann es eine Feineinstellung aufweisen.
Hinweis: V.22bis erfordert keine Echounterdrückung.
Wenn die Telco keinen rein digitalen Pfad zum Zugriffsserver bereitstellen kann, wird MICA (oder andere digitale Modems) nicht empfohlen. Es empfiehlt sich, analoge V.34-Modems wie Sara (integrierte analoge Microcom-Modems in Cisco 2600- oder 3600-Routern) zu verwenden.
Führen Sie die folgenden Schritte aus, um festzustellen, ob der Pfad zum Switch für digitale Modems geeignet ist:
Stellen Sie sicher, dass die DS1-Leitung für das Wählen eingerichtet ist.
Aktivieren Sie das Debug-Modem und das Debug-Modem csm oder debug csm-Modem, um zu ermitteln, welches Modem den Anruf entgegennimmt.
Stellen Sie eine umgekehrte Telnet-Verbindung zu einem Modem her, und tätigen Sie den Anruf.
Nach dem Hochfahren der Modems muss ein Teil des Datenverkehrs generiert werden (z. B. Anschlusslänge 0 und technischer Support). Aktivieren Sie anschließend das Kontrollkästchen "Betriebsstatus des Modems an beiden Enden".
Die typischsten Symptome, die auf Probleme bei der Leitung der nächsten Telco-Exchange hinweisen, sind:
Regelmäßige Wiederholungen von Fehlerkorrekturen (EC).
Kontinuierlicher Anstieg des Gesamtzählers der Züge.
Signal Quality (SQ)-Wert kleiner als drei.
Signal-Rausch-Verhältnis (SNR) unter 30 dB.
Der Empfangsbereich liegt deutlich unter der Übertragungsebene.
Nicht-Nullfrequenz-Offset, Phasenjitter-Frequenz, Phasenjitter-Pegel oder Phasenwalzen.
Echo-Pegel am äußersten Ende unter -40 dB.
Lücken in der Mitte der Linienform oder erhebliche Überrollgänge an den Kanten(n).
Das Near-End-Echo (auch als Talker oder Local bezeichnet) ist ein Teil des Signals eines Urhebers, der vom lokalen Hauptbüro (CO) über die Teilnehmeranschlussleitung des Urhebers an den Urheber zurückgegeben wird. Near-End-Echo wird in der Regel nur von Modems auf analogen Leitungen erkannt, da es durch Impedanzungleichheit bei der Hybrid verursacht wird. Dies ist der Transformator, der die zweiadrige analoge Schleife mit dem vieradrigen Telco-Übertragungsnetz verbindet.
Ein Far-End-Echo ist der Teil des übertragenen analogen Signals, der vom analogen Front-End des Remote-Modems abgeschnitten wurde.
Im folgenden Diagramm:
FEC = Far End Echo
NEC = Near End Echo
Moderne Modulationen (V.32 und höher) verwenden Echounterdrücker, um die gleichzeitige Nutzung von übertragenen und empfangenen Signalen im gleichen Frequenzband zu ermöglichen. Diese verfügen über einen digitalen Signalprozessor (Digital Signal Processor, DSP), um das übertragene Signal nachzuverfolgen und es dann vom empfangenen Signal abzuziehen. Moderne Client-Modems (auf der Seite der Analogleitung) enthalten sowohl End- als auch Remote-Echounterdrückung. MICA-Modems enthalten nur Echounterdrückung am anderen Ende, nicht aber Echounterdrückung am nahen Ende, da sie nicht erwarten, an eine analoge lokale Schleife angeschlossen zu werden. Bei einer digitalen lokalen Verbindung sollte es praktisch kein Nahecho geben.
Im Folgenden sind einige Beispiele für die Anzeige der Ausgabe des Modembetriebs von einem guten T1 (digital zum Switch) und einem schlechten (A-D konvertiert) T1 aufgeführt. Beachten Sie zusätzlich zum Unterschied beim Front-End-Echo auch die SNR-Differenz (41 dB gegenüber 35 dB), die zu einem perfekten 33600 Carrier im Vergleich zu einem mittelgroßen Carrier 28800 führt.
Gute Verbindung
isdn2-9>show modem operation 1/55 Modem(1/55) Operational-Status: Parameter #0 Disconnect Reason Info: (0x0) Type (=0 ): <unknown> Class (=0 ): Other Reason (=0 ): no disconnect has yet occurred Parameter #1 Connect Protocol: LAP-M Parameter #2 Compression: V.42bis both Parameter #3 EC Retransmission Count: 0 Parameter #4 Self Test Error Count: 0 Parameter #5 Call Timer: 44 secs Parameter #6 Total Retrains: 0 Parameter #7 Sq Value: 4 Parameter #8 Connected Standard: V.34+ Parameter #9 TX,RX Bit Rate: 33600, 33600 Parameter #11 TX,RX Symbol Rate: 3429, 3429 Parameter #13 TX,RX Carrier Frequency: 1959, 1959 Parameter #15 TX,RX Trellis Coding: 16, 16 Parameter #16 TX,RX Preemphasis Index: 0, 0 Parameter #17 TX,RX Constellation Shaping: Off, Off Parameter #18 TX,RX Nonlinear Encoding: Off, Off Parameter #19 TX,RX Precoding: Off, Off Parameter #20 TX,RX Xmit Level Reduction: 0, 0 dBm Parameter #21 Signal Noise Ratio: 41 dB Parameter #22 Receive Level: -12 dBm Parameter #23 Frequency Offset: 0 Hz Parameter #24 Phase Jitter Frequency: 0 Hz Parameter #25 Phase Jitter Level: 0 degrees Parameter #26 Far End Echo Level: -73 dBm Parameter #27 Phase Roll: 22 degrees Parameter #28 Round Trip Delay: 3 msecs Parameter #30 Characters transmitted, received: 83, 3194 Parameter #32 Characters received BAD: 0 Parameter #33 PPP/SLIP packets transmitted, received: 0, 0 Parameter #35 PPP/SLIP packets received (BAD/ABORTED): 0 Parameter #36 EC packets transmitted, received OK: 81, 105 Parameter #38 EC packets (Received BAD/ABORTED): 0 Parameter #39 Robbed Bit Signalling (RBS) pattern: 0 Parameter #40 Digital Pad: None, Digital Pad Compensation: None Line Shape: .........* ........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* *
Schlechter T1 (CAS) - Kanalbankverbindung zum Switch - Gegenstelle-Echo ist -36 dBm
term-server-1#show modem operation 1/38 Modem(1/38) Operational-Status: Parameter #0 Disconnect Reason Info: (0x0) Type (=0 ): <unknown> Class (=0 ): Other Reason (=0 ): no disconnect has yet occurred Parameter #1 Connect Protocol: LAP-M Parameter #2 Compression: V.42bis both Parameter #3 EC Retransmission Count: 2 Parameter #4 Self Test Error Count: 0 Parameter #5 Call Timer: 96 secs Parameter #6 Total Retrains: 1 Parameter #7 Sq Value: 3 Parameter #8 Connected Standard: V.34+ Parameter #9 TX,RX Bit Rate: 28800, 28800 Parameter #11 TX,RX Symbol Rate: 3429, 3429 Parameter #13 TX,RX Carrier Frequency: 1959, 1959 Parameter #15 TX,RX Trellis Coding: 16, 16 Parameter #16 TX,RX Preemphasis Index: 0, 6 Parameter #17 TX,RX Constellation Shaping: Off, Off Parameter #18 TX,RX Nonlinear Encoding: Off, Off Parameter #19 TX,RX Precoding: Off, Off Parameter #20 TX,RX Xmit Level Reduction: 0, 0 dBm Parameter #21 Signal Noise Ratio: 35 dB Parameter #22 Receive Level: -13 dBm Parameter #23 Frequency Offset: 0 Hz Parameter #24 Phase Jitter Frequency: 0 Hz Parameter #25 Phase Jitter Level: 0 degrees Parameter #26 Far End Echo Level: -36 dBm Parameter #27 Phase Roll: 0 degrees Parameter #28 Round Trip Delay: 6 msecs Parameter #30 Characters transmitted, received: 8636, 116 Parameter #32 Characters received BAD: 0 Parameter #33 PPP/SLIP packets transmitted, received: 0, 0 Parameter #35 PPP/SLIP packets received (BAD/ABORTED): 0 Parameter #36 EC packets transmitted, received OK: 124, 63 Parameter #38 EC packets (Received BAD/ABORTED): 4 Parameter #39 Robbed Bit Signalling (RBS) pattern: 0 Parameter #40 Digital Pad: None, Digital Pad Compensation: None Line Shape: .........* ......* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .......* ........* *
Weitere Informationen finden Sie unter Übersicht über die allgemeine Modem- und NAS-Leitungsqualität und diesem Versionshinweis.
Wenn die Tests keine Probleme mit der Leitung ergeben, fahren Sie mit dem Telco weiter entlang der Anrufpfade fort.
Anrufe von verschiedenen Standorten mit verschiedenen Modemmodellen an bestimmte Nummern (DS1 oder Zugriffsserver) weisen eine schlechte Konnektivität auf, was niedrige Verbindungsgeschwindigkeiten, häufig Neuzüge, hohe Fehlerquoten usw. angeht. Dieselben Clients an denselben Standorten verfügen über gute Verbindungen, wenn sie andere lokale Nummern anrufen (z. B. das San-Jose Dial-in Lab oder das Australia Dial-in Lab).
Überprüfen Sie die Statistiken auf Controller- und Schnittstellenebene auf Fehler (weitere Informationen finden Sie in der Einführung). Wenn der Zugriffsserver beispielsweise mehr als eine Telco-Leitung terminiert, stellen Sie sicher, dass alle Leitungen synchronisiert sind (in der Regel bedeutet dies, dass die Leitungen vom gleichen Anbieter übernommen werden müssen), wie in der Uhrsynchronisierung erläutert. Die Überprüfung muss sowohl auf der Seite des Zugangs-Servers als auch auf der Seite des Telekoals erfolgen (wenn das Problem die Signale beeinflusst, die vom Zugangs-Server zur nächsten Telco-Exchange kommen, kann der Zugriffsserver keine Fehler melden).
Wenn Sie überprüft haben, dass auf der T1- oder E1-Ebene alles in Ordnung ist, sich die Vorgänge auf der Modemschicht jedoch nicht gut verhalten, sollten Sie Folgendes überprüfen:
Sammeln Sie repräsentative Statistiken (siehe auch Hinweis 1), auf welcher Seite die Verbindungen getrennt werden, und aus welchem Grund. Die Gründe für die Trennung vom Zugriffsserver werden unter folgender Adresse erläutert:
Prüfen Sie, ob FineTuning-Modems Auswirkungen auf Verbindungszeiten oder Verbindungsunterbrechungen haben.
Stellen Sie sicher, dass Sie einen guten Modemcode verwenden (siehe FineTuning Modems).
Stellen Sie sicher, dass Sie die DS0-Pfade durch das Telco einstellen, um eine optimale Leistung zu erzielen. Beachten Sie, dass sich Suboptimalitäten an einer beliebigen Stelle im DS0/3.1KHz-Pfad befinden:
Innerhalb der Verkabelung des Client-Modems (z. B. Nebenstellen).
Die Teilnehmerschleife des Kunden (lange Schleife, Lastspulen, Überbrückungshähne).
Innerhalb einer Switch-Konfiguration zu viel - oder nicht genug - digitales oder analoges Padding
Problematische Trunks innerhalb des Telco (alte Mikrowellenverbindungen, alte E&M-vieradrige analoge Trunks).
Um das (größtenteils) lokale Telco-Netzwerk-Übertragungsnetz und die lokalen Schleifen zu berücksichtigen, ist es empfehlenswert, sich von einem zweifelsfrei funktionierenden Client (Modem und Schleife zum nächsten Telco-Switch) aus in den Zielzugriffsserver einzuwählen. Wenn Sie eine Verbindung in der gewünschten Qualität erhalten, beweist dies, dass der Zugriffsserver, seine Modems und seine DS1-Leitung fehlerfrei funktionieren.
Führen Sie die folgenden Schritte aus, um festzustellen, ob der Pfad zum Switch für digitale Modems geeignet ist:
Stellen Sie sicher, dass die DS1-Leitung für das Wählen eingerichtet ist.
Aktivieren Sie das Debug-Modem und das Debug-Modem csm oder debug csm-Modem, um zu ermitteln, welches Modem den Anruf entgegennimmt.
Stellen Sie eine umgekehrte Telnet-Verbindung zu einem Modem her, und tätigen Sie den Anruf.
Nach dem Hochfahren der Modems muss ein Teil des Datenverkehrs generiert werden (z. B. Anschlusslänge 0 und technischer Support). Aktivieren Sie anschließend das Kontrollkästchen "Betriebsstatus des Modems an beiden Enden".
Die typischsten Symptome, die auf Probleme bei der Leitung der nächsten Telco-Exchange hinweisen, sind:
Regelmäßige Wiederholungen von Fehlerkorrekturen (EC).
Kontinuierlicher Anstieg des Gesamtzählers der Züge.
Signal Quality (SQ)-Wert kleiner als drei.
Signal-Rausch-Verhältnis (SNR) unter 30 dB.
Der Empfangsbereich liegt deutlich unter der Übertragungsebene.
Nicht-Nullfrequenz-Offset, Phasenjitter-Frequenz, Phasenjitter-Pegel oder Phasenwalzen.
Echo-Pegel am äußersten Ende unter -40 dB.
Lücken in der Mitte der Linienform oder erhebliche Überrollgänge an den Kanten(n).
Near-End-Echo (auch als Talker oder Local bezeichnet) ist ein Teil des Signals eines Originators, der vom lokalen CO über die lokale Schleife des Originators zurück zum Ausgangspunkt reflektiert wird. Near-End-Echo wird in der Regel nur von Modems auf analogen Leitungen erkannt, da es durch Impedanzungleichheit bei der Hybrid verursacht wird. Dies ist der Transformator, der die zweiadrige analoge Schleife mit dem vieradrigen Telco-Übertragungsnetz verbindet.
Ein Far-End-Echo ist der Teil des übertragenen analogen Signals, der vom analogen Front-End des Remote-Modems abgeschnitten wurde.
Im folgenden Diagramm:
FEC = Far End Echo
NEC = Near End Echo
Moderne Modulationen (V.32 und höher) verwenden Echounterdrücker, um die gleichzeitige Nutzung von übertragenen und empfangenen Signalen im gleichen Frequenzband zu ermöglichen. Diese verfügen über einen DSP, der das übertragene Signal verfolgt und dieses dann vom empfangenen Signal abzieht. Moderne Client-Modems (auf der Seite der Analogleitung) enthalten sowohl End- als auch Remote-Echounterdrückung. MICA-Modems enthalten nur Echounterdrückung am anderen Ende, nicht aber Echounterdrückung am nahen Ende, da sie nicht erwarten, an eine analoge lokale Schleife angeschlossen zu werden. Bei einer digitalen lokalen Verbindung sollte es (praktisch) kein Nahecho geben.
Hier sind einige Beispiele für die Anzeige des Betriebsstatus eines Modems von "Gut" (digital zu Switch) und "Schlecht" (A-D konvertiert) von "T1". Beachten Sie zusätzlich zum Unterschied beim Front-End-Echo auch die SNR-Differenz (41 dB gegenüber 35 dB), die zu einem perfekten 33600 Carrier im Vergleich zu einem mittelgroßen Carrier 28800 führt.
Gute Verbindung
isdn2-9>show modem operation 1/55 Modem(1/55) Operational-Status: Parameter #0 Disconnect Reason Info: (0x0) Type (=0 ): <unknown> Class (=0 ): Other Reason (=0 ): no disconnect has yet occurred Parameter #1 Connect Protocol: LAP-M Parameter #2 Compression: V.42bis both Parameter #3 EC Retransmission Count: 0 Parameter #4 Self Test Error Count: 0 Parameter #5 Call Timer: 44 secs Parameter #6 Total Retrains: 0 Parameter #7 Sq Value: 4 Parameter #8 Connected Standard: V.34+ Parameter #9 TX,RX Bit Rate: 33600, 33600 Parameter #11 TX,RX Symbol Rate: 3429, 3429 Parameter #13 TX,RX Carrier Frequency: 1959, 1959 Parameter #15 TX,RX Trellis Coding: 16, 16 Parameter #16 TX,RX Preemphasis Index: 0, 0 Parameter #17 TX,RX Constellation Shaping: Off, Off Parameter #18 TX,RX Nonlinear Encoding: Off, Off Parameter #19 TX,RX Precoding: Off, Off Parameter #20 TX,RX Xmit Level Reduction: 0, 0 dBm Parameter #21 Signal Noise Ratio: 41 dB Parameter #22 Receive Level: -12 dBm Parameter #23 Frequency Offset: 0 Hz Parameter #24 Phase Jitter Frequency: 0 Hz Parameter #25 Phase Jitter Level: 0 degrees Parameter #26 Far End Echo Level: -73 dBm Parameter #27 Phase Roll: 22 degrees Parameter #28 Round Trip Delay: 3 msecs Parameter #30 Characters transmitted, received: 83, 3194 Parameter #32 Characters received BAD: 0 Parameter #33 PPP/SLIP packets transmitted, received: 0, 0 Parameter #35 PPP/SLIP packets received (BAD/ABORTED): 0 Parameter #36 EC packets transmitted, received OK: 81, 105 Parameter #38 EC packets (Received BAD/ABORTED): 0 Parameter #39 Robbed Bit Signalling (RBS) pattern: 0 Parameter #40 Digital Pad: None, Digital Pad Compensation: None Line Shape: .........* ........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* *
Schlechter T1 (CAS) - Kanalbankverbindung zum Switch - Gegenstelle-Echo ist -36 dBm
term-server-1#show modem operation 1/38 Modem(1/38) Operational-Status: Parameter #0 Disconnect Reason Info: (0x0) Type (=0 ): <unknown> Class (=0 ): Other Reason (=0 ): no disconnect has yet occurred Parameter #1 Connect Protocol: LAP-M Parameter #2 Compression: V.42bis both Parameter #3 EC Retransmission Count: 2 Parameter #4 Self Test Error Count: 0 Parameter #5 Call Timer: 96 secs Parameter #6 Total Retrains: 1 Parameter #7 Sq Value: 3 Parameter #8 Connected Standard: V.34+ Parameter #9 TX,RX Bit Rate: 28800, 28800 Parameter #11 TX,RX Symbol Rate: 3429, 3429 Parameter #13 TX,RX Carrier Frequency: 1959, 1959 Parameter #15 TX,RX Trellis Coding: 16, 16 Parameter #16 TX,RX Preemphasis Index: 0, 6 Parameter #17 TX,RX Constellation Shaping: Off, Off Parameter #18 TX,RX Nonlinear Encoding: Off, Off Parameter #19 TX,RX Precoding: Off, Off Parameter #20 TX,RX Xmit Level Reduction: 0, 0 dBm Parameter #21 Signal Noise Ratio: 35 dB Parameter #22 Receive Level: -13 dBm Parameter #23 Frequency Offset: 0 Hz Parameter #24 Phase Jitter Frequency: 0 Hz Parameter #25 Phase Jitter Level: 0 degrees Parameter #26 Far End Echo Level: -36 dBm Parameter #27 Phase Roll: 0 degrees Parameter #28 Round Trip Delay: 6 msecs Parameter #30 Characters transmitted, received: 8636, 116 Parameter #32 Characters received BAD: 0 Parameter #33 PPP/SLIP packets transmitted, received: 0, 0 Parameter #35 PPP/SLIP packets received (BAD/ABORTED): 0 Parameter #36 EC packets transmitted, received OK: 124, 63 Parameter #38 EC packets (Received BAD/ABORTED): 4 Parameter #39 Robbed Bit Signalling (RBS) pattern: 0 Parameter #40 Digital Pad: None, Digital Pad Compensation: None Line Shape: .........* ......* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .......* ........* *
Weitere Informationen finden Sie unter Übersicht über die allgemeine Modem- und NAS-Leitungsqualität und diesem Versionshinweis.
Wenn Schleifen zu den nächstgelegenen Telco-Switches (sowohl von der Client- als auch von der Access-Server-Seite) sauber erscheinen und die Suboptimalität irgendwo im Telco-Pfad liegt, können Sie hier einige Dinge tun:
Führen Sie einen Nicht-EC-Anruf in V.22bis mit 2400 bit/s durch. Wenn die Leitung gesund ist, sollte es praktisch keine Fehler zu sehen. Wenn Sie die Verbindung im Leerlauf sitzen lassen und wiederkehrende Fehler sehen (insbesondere bei Code 0x7B, '{' in ASCII), zeigt dies das Vorhandensein (gesteuerter) Zeitschlitze an (z. B. innerhalb der T-Spans von Telco, selten sichtbar)
Wenn die auf unseren Clients angezeigten Leistungspegel für Übertragung oder Empfang zu hoch oder zu niedrig sind, passen Sie die Übertragungsstufen an, und fügen Sie die Leitungs- oder Trunk-Padding hinzu oder entfernen Sie sie.
Wenn Sie einen gesunden V.34-Carrier sehen, aber eine schwache oder keine Pulse-Code-Modulation (PCM) erhalten (wobei der PCM-Code auf den Clients bekanntermaßen mit den Servermodems kompatibel ist):
Überprüfen Sie, ob die Schaltungspfade zu den Client-Modems eine PCM-Verbindung aufrechterhalten können. Mit anderen Leitungen sollten Sie sicherstellen, dass keine zusätzliche analoge oder digitale Konvertierung möglich ist.
Untersuchen Sie das digitale Padding im Pfad.
Fahren Sie mit Telco fort, um weitere Informationen über die Anrufpfade zu erhalten.
Anrufe von verschiedenen Standorten mit verschiedenen Modemmodellen an bestimmte Nummern (DS1 oder Zugriffsserver) stellen eine Verbindung her, aber später wird der Anruf beendet. Dieselben Clients an denselben Standorten verfügen über gute Verbindungen, wenn sie andere lokale Nummern anrufen (z. B. das San-Jose Dial-in Lab oder das Australia Dial-in Lab).
Überprüfen Sie zunächst die Statistiken auf Controller- und Schnittstellenebene auf Fehler (weitere Informationen finden Sie in der Einführung). Wenn der Zugriffsserver beispielsweise mehr als eine Telco-Leitung terminiert, stellen Sie sicher, dass alle Leitungen synchronisiert sind (in der Regel bedeutet dies, dass die Leitungen vom gleichen Anbieter übernommen werden müssen), wie in der Uhrsynchronisierung erläutert. Die Überprüfung muss sowohl auf der Seite des Zugangs-Servers als auch auf der Seite des Telekoals erfolgen (wenn das Problem die Signale beeinflusst, die vom Zugangs-Server zur nächsten Telco-Exchange kommen, kann der Zugriffsserver keine Fehler melden).
Stellen Sie anschließend sicher, dass die Anrufe den Zugriffsserver erreichen, wie in der Dialup-Technologie erläutert: Fehlerbehebungsverfahren. Überprüfen Sie anschließend die Anrufzähler show controller <e1|t1>. Bei einigen Telco-Problemen melden bestimmte DS0-Kanäle in der Regel sehr niedrige Verbindungszeiten und eine sehr hohe Anzahl von Anrufen. Ermitteln Sie repräsentative Statistiken (siehe Anmerkung 1), auf denen die Seite die Verbindung trennt, und warum:
Legt fest, ob eine PPP-Kündigung angefordert wurde. Siehe DFÜ-Technologie: Fehlerbehebungsverfahren.
Legt fest, ob eine Modemterminierung angefordert wurde. Die Modemtrennungsgründe im Modemprotokoll werden unter folgender Adresse erläutert:
ISDN Trennungsursache. (Siehe auch Hinweis 3).
Wenn die Verbindung bei den Anrufen aufgrund häufiger Verbindungsfehler getrennt wird, prüfen Sie, ob FineTuning-Modems Auswirkungen auf die Verbindungszeiten und/oder Verbindungsunterbrechungen haben.
Stellen Sie sicher, dass Sie einen guten Modemcode verwenden (siehe FineTuning Modems).
Stellen Sie sicher, dass Sie die DS0-Pfade durch das Telco einstellen, um eine optimale Leistung zu erzielen. Beachten Sie, dass sich Suboptimalitäten an einer beliebigen Stelle im DS0/3.1KHz-Pfad befinden:
Innerhalb der Verkabelung des Client-Modems (z. B. Nebenstellen).
Die Teilnehmerschleife des Kunden (lange Schleife, Lastspulen, Überbrückungshähne).
Innerhalb einer Switch-Konfiguration zu viel - oder nicht genug - digitales oder analoges Padding
Problematische Trunks innerhalb des Telco (alte Mikrowellenverbindungen, alte E&M-vieradrige analoge Trunks).
Um das (größtenteils) lokale Telco-Netzwerk-Übertragungsnetz und die lokalen Schleifen zu berücksichtigen, ist es empfehlenswert, sich von einem zweifelsfrei funktionierenden Client (Modem und Schleife zum nächsten Telco-Switch) aus in den Zielzugriffsserver einzuwählen. Wenn Sie eine Verbindung in der gewünschten Qualität erhalten, beweist dies, dass der Zugriffsserver, seine Modems und seine DS1-Leitung fehlerfrei funktionieren.
Führen Sie die folgenden Schritte aus, um festzustellen, ob der Pfad zum Switch für digitale Modems geeignet ist:
Stellen Sie sicher, dass die DS1-Leitung für das Wählen eingerichtet ist.
Aktivieren Sie das Debug-Modem und das Debug-Modem csm oder debug csm-Modem, um zu ermitteln, welches Modem den Anruf entgegennimmt.
Stellen Sie eine umgekehrte Telnet-Verbindung zu einem Modem her, und tätigen Sie den Anruf.
Nach dem Hochfahren der Modems sollten Sie Datenverkehr generieren (z. B. Terminal-Länge 0 und technischen Support anzeigen). Aktivieren Sie dann das Kontrollkästchen Betriebsstatus des Modems an beiden Enden.
Die typischsten Symptome, die auf Probleme bei der Leitung der nächsten Telco-Exchange hinweisen, sind:
Regelmäßige Wiederholungen von Fehlerkorrekturen (EC).
Kontinuierlicher Anstieg des Gesamtzählers der Züge.
Signal Quality (SQ)-Wert kleiner als drei.
Signal-Rausch-Verhältnis (SNR) unter 30 dB.
Der Empfangsbereich liegt deutlich unter der Übertragungsebene.
Nicht-Nullfrequenz-Offset, Phasenjitter-Frequenz, Phasenjitter-Pegel oder Phasenwalzen.
Echo-Pegel am äußersten Ende unter -40 dB.
Lücken in der Mitte der Linienform oder erhebliche Überrollgänge an den Kanten(n).
Near-End-Echo (auch als Talker oder Local bezeichnet) ist ein Teil des Signals eines Originators, der vom lokalen CO über die lokale Schleife des Originators zurück zum Ausgangspunkt reflektiert wird. Near-End-Echo wird in der Regel nur von Modems auf analogen Leitungen erkannt, da es durch Impedanzungleichheit bei der Hybrid verursacht wird. Dies ist der Transformator, der die zweiadrige analoge Schleife mit dem vieradrigen Telco-Übertragungsnetz verbindet.
Ein Far-End-Echo ist der Teil des übertragenen analogen Signals, der vom analogen Front-End des Remote-Modems abgeschnitten wurde.
Ein Far-End-Echo ist der Teil des übertragenen analogen Signals, der vom analogen Front-End des Remote-Modems abgeschnitten wurde.
Im folgenden Diagramm:
FEC = Far End Echo
NEC = Near End Echo
Moderne Modulationen (V.32 und höher) verwenden Echounterdrücker, um die gleichzeitige Nutzung von übertragenen und empfangenen Signalen im gleichen Frequenzband zu ermöglichen. Diese verfügen über einen DSP, der das übertragene Signal verfolgt und dieses dann vom empfangenen Signal abzieht. Moderne Client-Modems (auf der Seite der Analogleitung) enthalten sowohl End- als auch Remote-Echounterdrückung. MICA-Modems enthalten nur Echounterdrückung am anderen Ende, nicht aber Echounterdrückung am nahen Ende, da sie nicht erwarten, an eine analoge lokale Schleife angeschlossen zu werden. Bei einer digitalen lokalen Verbindung sollte es (praktisch) kein Nahecho geben.
Hier sind einige Beispiele für die Anzeige des Betriebsstatus eines Modems von "Gut" (digital zu Switch) und "Schlecht" (A-D konvertiert) von "T1". Beachten Sie zusätzlich zum Unterschied beim Front-End-Echo auch die SNR-Differenz (41 dB gegenüber 35 dB), die zu einem perfekten 33600 Carrier im Vergleich zu einem mittelgroßen Carrier 28800 führt.
Gute Verbindung
isdn2-9>show modem operational 1/55 Modem(1/55) Operational-Status: Parameter #0 Disconnect Reason Info: (0x0) Type (=0 ): <unknown> Class (=0 ): Other Reason (=0 ): no disconnect has yet occurred Parameter #1 Connect Protocol: LAP-M Parameter #2 Compression: V.42bis both Parameter #3 EC Retransmission Count: 0 Parameter #4 Self Test Error Count: 0 Parameter #5 Call Timer: 44 secs Parameter #6 Total Retrains: 0 Parameter #7 Sq Value: 4 Parameter #8 Connected Standard: V.34+ Parameter #9 TX,RX Bit Rate: 33600, 33600 Parameter #11 TX,RX Symbol Rate: 3429, 3429 Parameter #13 TX,RX Carrier Frequency: 1959, 1959 Parameter #15 TX,RX Trellis Coding: 16, 16 Parameter #16 TX,RX Preemphasis Index: 0, 0 Parameter #17 TX,RX Constellation Shaping: Off, Off Parameter #18 TX,RX Nonlinear Encoding: Off, Off Parameter #19 TX,RX Precoding: Off, Off Parameter #20 TX,RX Xmit Level Reduction: 0, 0 dBm Parameter #21 Signal Noise Ratio: 41 dB Parameter #22 Receive Level: -12 dBm Parameter #23 Frequency Offset: 0 Hz Parameter #24 Phase Jitter Frequency: 0 Hz Parameter #25 Phase Jitter Level: 0 degrees Parameter #26 Far End Echo Level: -73 dBm Parameter #27 Phase Roll: 22 degrees Parameter #28 Round Trip Delay: 3 msecs Parameter #30 Characters transmitted, received: 83, 3194 Parameter #32 Characters received BAD: 0 Parameter #33 PPP/SLIP packets transmitted, received: 0, 0 Parameter #35 PPP/SLIP packets received (BAD/ABORTED): 0 Parameter #36 EC packets transmitted, received OK: 81, 105 Parameter #38 EC packets (Received BAD/ABORTED): 0 Parameter #39 Robbed Bit Signalling (RBS) pattern: 0 Parameter #40 Digital Pad: None, Digital Pad Compensation: None Line Shape: .........* ........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* *
Schlechter T1 (CAS) - Kanalbankverbindung zum Switch - Gegenstelle-Echo ist -36 dBm
term-server-1#show modem operational 1/38 Modem(1/38) Operational-Status: Parameter #0 Disconnect Reason Info: (0x0) Type (=0 ): <unknown> Class (=0 ): Other Reason (=0 ): no disconnect has yet occurred Parameter #1 Connect Protocol: LAP-M Parameter #2 Compression: V.42bis both Parameter #3 EC Retransmission Count: 2 Parameter #4 Self Test Error Count: 0 Parameter #5 Call Timer: 96 secs Parameter #6 Total Retrains: 1 Parameter #7 Sq Value: 3 Parameter #8 Connected Standard: V.34+ Parameter #9 TX,RX Bit Rate: 28800, 28800 Parameter #11 TX,RX Symbol Rate: 3429, 3429 Parameter #13 TX,RX Carrier Frequency: 1959, 1959 Parameter #15 TX,RX Trellis Coding: 16, 16 Parameter #16 TX,RX Preemphasis Index: 0, 6 Parameter #17 TX,RX Constellation Shaping: Off, Off Parameter #18 TX,RX Nonlinear Encoding: Off, Off Parameter #19 TX,RX Precoding: Off, Off Parameter #20 TX,RX Xmit Level Reduction: 0, 0 dBm Parameter #21 Signal Noise Ratio: 35 dB Parameter #22 Receive Level: -13 dBm Parameter #23 Frequency Offset: 0 Hz Parameter #24 Phase Jitter Frequency: 0 Hz Parameter #25 Phase Jitter Level: 0 degrees Parameter #26 Far End Echo Level: -36 dBm Parameter #27 Phase Roll: 0 degrees Parameter #28 Round Trip Delay: 6 msecs Parameter #30 Characters transmitted, received: 8636, 116 Parameter #32 Characters received BAD: 0 Parameter #33 PPP/SLIP packets transmitted, received: 0, 0 Parameter #35 PPP/SLIP packets received (BAD/ABORTED): 0 Parameter #36 EC packets transmitted, received OK: 124, 63 Parameter #38 EC packets (Received BAD/ABORTED): 4 Parameter #39 Robbed Bit Signalling (RBS) pattern: 0 Parameter #40 Digital Pad: None, Digital Pad Compensation: None Line Shape: .........* ......* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .......* ........* *
Weitere Informationen finden Sie unter Übersicht über die allgemeine Modem- und NAS-Leitungsqualität und diesem Versionshinweis.
Wenn Schleifen zu den nächstgelegenen Telco-Switches (sowohl von der Client- als auch von der Access-Server-Seite) sauber erscheinen und die Suboptimalität irgendwo im Telco-Pfad liegt, können Sie hier einige Dinge tun:
Führen Sie einen Nicht-EC-Anruf in V.22bis mit 2400 bit/s durch. Wenn die Leitung gesund ist, sollte es praktisch keine Fehler zu sehen. Wenn Sie die Verbindung im Leerlauf sitzen lassen und wiederkehrende Fehler sehen (insbesondere bei Code 0x7B, '{' in ASCII), zeigt dies das Vorhandensein (gesteuerter) Zeitschlitze an (z. B. innerhalb der T-Spans von Telco, selten sichtbar)
Wenn die auf unseren Clients angezeigten Leistungspegel für Übertragung oder Empfang zu hoch oder zu niedrig sind, passen Sie die Übertragungsstufen an, und fügen Sie die Leitungs- oder Trunk-Padding hinzu oder entfernen Sie sie.
Wenn Sie einen gesunden V.34-Carrier sehen, aber eine schwache oder keine Pulse-Code-Modulation (PCM) erhalten (wobei der PCM-Code auf den Clients bekanntermaßen mit den Servermodems kompatibel ist):
Überprüfen Sie, ob die Schaltungspfade zu den Client-Modems eine PCM-Verbindung aufrechterhalten können. Mit anderen Leitungen sollten Sie sicherstellen, dass keine zusätzliche analoge oder digitale Konvertierung möglich ist.
Untersuchen Sie das digitale Padding im Pfad.
Fahren Sie mit Telco fort, um weitere Informationen über die Anrufpfade zu erhalten.
Gehen Sie wie folgt vor, um dieses Problem zu beheben:
Überprüfen Sie, ob der Anruf mit der DFÜ-Technologie am Zugriffsserver eingeht: Fehlerbehebungsverfahren.
Überprüfen Sie, ob die ISDN-Anrufe die richtige Trägerfunktion haben, und stellen Sie sicher, dass DoV nicht konfiguriert ist.
Überprüfen Sie, ob die Modems für die Annahme von Sprachanrufen konfiguriert sind.
Stellen Sie sicher, dass die Modemcap-Einstellungen, wie in Modem Management Operations (siehe auch Hinweis 2) erläutert, korrekt sind (z. B. ist das S0-Register nicht auf 0 oder zu hoch für einen Wert festgelegt):
Wenn RPM oder RPMS verwendet wird, überprüfen Sie zuerst, ob das Problem weiterhin besteht, nachdem die Funktion deaktiviert wurde. Wenn dies hilft, fahren Sie mit dem lokal konfigurierten RPM fort und überprüfen Sie die Modemcap-Einstellungen.
Überprüfen Sie, ob die B-Kanäle nicht besetzt sind (show isdn active) und dass kostenlose Modems (show modem) vorhanden sind. Wenn die Modems als fehlerhaft gekennzeichnet sind, kann es sich um ein Hardware- oder Softwareproblem handeln.
Hardwarefehler treten in der Regel bei einer bestimmten Carrier Card oder einer bestimmten Modemkarte auf. Modems müssen nicht unbedingt als "schlecht" gekennzeichnet werden, sie schlagen jedoch bei allen Anrufen seit dem Hochfahren fehl. Die Lösung ist Hardware-Ersatz.
Im Falle eines Softwareausfalls funktionieren die Modems nach jedem Neustart in der Regel einwandfrei, werden jedoch später zufällig als "schlecht" gekennzeichnet (kann in Clustern mit einer, zwei, drei, sechs oder 12 auf derselben Modemkarte liegen) oder fallen einfach alle weiteren Anrufe aus. Wenn das Problem nur zu Spitzenzeiten auftritt, überprüfen Sie die Modemstatistiken anzeigen Modem. Eine hohe, gleichmäßig auf alle Modems verteilte Quote für "Keine Antwort" bedeutet, dass der Zugriffsserver eine solche Anzahl von Anrufen einfach nicht verarbeiten kann. Wenn eine hohe Rate von "No Answer" (Keine Antwort) nur für wenige Modems gilt, ist es weiterhin wahrscheinlich, dass ein Softwarefehler auftritt. Das erneute Laden der Firmware ist eine Lösung. Die Lösung besteht darin, Software zu aktualisieren und die automatische Wiederherstellung des Modems zu aktivieren (bei Cisco 3600-Routern muss das Netzwerkmodul [NM] möglicherweise ausgetauscht werden, wenn die Ausgabe des Befehls show diag anzeigt, dass die Teilenummer nicht -02-Version ist: 800-0553x-02). Weitere Informationen finden Sie unter MICA und NextPort Modems.
Manchmal nehmen Modems Anrufe entgegen, aber sie trainieren nicht. Um dies zu überprüfen, sammeln Sie repräsentative Statistiken (siehe auch Anmerkung 1), auf welcher Seite die Verbindung getrennt wird, und was der Grund dafür ist. Auf der Seite "Access Server" werden die Gründe für die Trennung erläutert unter:
Auch die CSR-Werte müssen sinken, und die Modems müssen mitten in den Modemzustandswechseln abbrechen.
Überprüfen Sie zunächst, ob das Modemland korrekt konfiguriert ist. Prüfen Sie, ob der Controller oder die Schnittstelle auf beiden Seiten des Zugangs-Servers und der Telco-Seite Fehler aufweisen (wenn das Problem die Signale betrifft, die vom Zugangs-Server an die nächstgelegene Telekommunikationszentrale gesendet werden, kann der Zugriffsserver keine Fehler melden). Wenn RPM oder RPMS verwendet wird, überprüfen Sie, ob das Problem weiterhin besteht, nachdem die Funktion deaktiviert wurde. Versuchen Sie anschließend mit lokal konfiguriertem RPM, und überprüfen Sie, ob die Modemcap-Einstellungen, wie in Modem Management Operations (Modemmanagement-Operationen) erläutert (siehe Hinweis 2), korrekt sind:
Überprüfen Sie die Modemstatistiken mit dem Befehl show modem (MICA) oder show spe (NextPort). Wenn Cluster mit einem, zwei, drei, sechs oder zwölf Modems innerhalb derselben Modemkarte ungewöhnlich viele fehlgeschlagene Anrufe haben oder als fehlerhaft gekennzeichnet sind, kann es sich entweder um ein Hardware- oder ein Softwareproblem handeln.
Bei Hardwareausfällen ist es in der Regel erforderlich, bei einer bestimmten Carrier Card oder Modemkarte zu bleiben. Modems müssen nicht unbedingt als "schlecht" gekennzeichnet werden, sie schlagen jedoch alle Anrufe seit dem Hochfahren fehl. Die Lösung ist Hardware-Ersatz.
Bei einem Softwareausfall ist es typisch, dass die Modems nach jedem Neustart einwandfrei funktionieren, später jedoch zufällig als "schlecht" gekennzeichnet werden (in Clustern mit einer, zwei, drei, sechs oder zwölf auf derselben Modemkarte) oder einfach alle weiteren Anrufe fehlschlagen. Das erneute Laden der Firmware ist eine Lösung. Die Lösung besteht darin, Software zu aktualisieren und die automatische Wiederherstellung des Modems zu aktivieren (bei Cisco 3600-Routern muss das NM möglicherweise ersetzt werden, wenn die Ausgabe von show diag zeigt, dass die Teilenummer nicht -02-Version ist: 800-0553x-02). Weitere Informationen finden Sie unter MICA und NextPort Modems.
Wenn das Problem nicht speziell auf die Architektur des Zugriffsservers zurückzuführen ist, prüfen Sie, ob FineTuning Modems Auswirkungen auf Verbindungszeiten und Verbindungsunterbrechungen haben.
Diese Probleme können gleichermaßen Telco, Client-Modem oder dem Zugriffsserver zugeschrieben werden. Wenn keine vorherigen Statistiken für den Standort verfügbar sind, können die Empfehlungen der ITU-T V.56-Serie als erste Annäherung an die Verbindungsraten dienen, in denen Sie die erwartete Anzahl an Anschlüssen erwarten können. Überprüfen Sie den Controller und die Benutzeroberfläche auf Fehler. Die Überprüfung muss sowohl auf der Seite des Zugangs-Servers als auch auf der Seite des Teleco-Geräts erfolgen (wenn das Problem die Signale betrifft, die vom Zugangs-Server zur nächsten Telco-Exchange kommen, kann der Zugriffsserver keine Fehler melden). Möglicherweise ist es auch erforderlich, die Telco-Verbindung weiter auf dem Weg fortzusetzen.
Wenn RPM oder RPMS verwendet wird, überprüfen Sie zuerst, ob das Problem weiterhin besteht, nachdem die Funktion deaktiviert wurde. Wenn dies hilft, untersuchen Sie lokal konfiguriertes RPM und modemcap, wie unten erläutert.
Überprüfen Sie, ob die Modemcap-Einstellungen, wie unter Modem Management Operations (Modemmanagement-Vorgänge) erläutert (siehe Hinweis 2), korrekt sind:
Testen Sie Fine-Tuning Modems, und prüfen Sie, ob diese bei jedem Modemansatz Verbesserungen bewirken. Überprüfen Sie die Verbindungsparameter für bestimmte Anrufe mit Anzeige des Betriebsstatus des Modems, wie unter Übersicht über die allgemeine Modem- und NAS-Leitungsqualität und in diesem Versionshinweis beschrieben, um mögliche Probleme zu identifizieren.
Um dies zu überprüfen, überprüfen Sie den Trennungsgrund in den Modemprotokollen. Stellen Sie sicher, dass die CSR-Anzeige nicht abnimmt und die Modems alle Zustandsübergänge erfolgreich durchlaufen. Bei der Konfigurationsprüfung:
Legt fest, ob PPP auf dem Zugriffsserver im interaktiven oder dedizierten Modus konfiguriert wird. Wenn PPP auf eine interaktive Auswahl festgelegt ist und der Client keine PPP-Autoauswahlsequenz sendet, wie in RFC 1662 angegeben, ist eine PPP-Verbindung aus Sicht des Zugangs-Servers unmöglich. Untersuchen Sie die Client-Seite oder Telco.
Legt fest, ob Modemleitungen und Modemschnittstellen (in der Regel Gruppen-Async) korrekt konfiguriert sind (für Beispielkonfigurationen siehe Einführung in diesen Abschnitt bzw. Dialup-Technologie: Fehlerbehebungsverfahren).
Legt fest, ob Modems außerhalb des Gruppenbereichs für asynchrone Schnittstellen verwaist bleiben. Keiner sollte verwaist bleiben.
Überprüfen Sie, ob die Clients, das Telco oder der Zugriffsserver die Trennlinien initiieren.
Prüfen Sie zuerst, ob die PPP-Verbindung ordnungsgemäß beendet wurde (diese Trennung kann vom Client oder vom Zugriffsserver initiiert werden). Verwenden Sie hierzu die Dialup-Technologie: Fehlerbehebungsverfahren.
Wenn die PPP nicht ordnungsgemäß beendet wurde, kann dies der Grund für das Telco sein. Dekodieren Sie die Trennungsgründe im Modemprotokoll. (Siehe auch Hinweis 1).
Wenn die Modems auch eine unerwartete Trennung melden, kann das Telco-Gerät Fehler aufweisen. Es empfiehlt sich, die Gründe für die Trennung von beiden Enden der Verbindung zu vergleichen. Siehe ISDN-Trennungsursache. (Siehe auch Hinweis 3).
Wenn der Zugriffsserver die Verbindung getrennt hat, überprüfen Sie, ob der interessante Datenverkehr auf der entsprechenden Dialer-Schnittstelle richtig definiert ist. Der Befehl debug dialer events sollte einen Bericht erstellen, wenn der Zugriffsserver bei Timeout die Verbindung von Anrufen getrennt hat.
Wenn die Verwerfen von Clients initiiert werden, ist die Fehlerbehebung beim Zugriffsserver unwahrscheinlich. Testen Sie die Empfehlungen aus dem Abschnitt zur Fehlerbehebung für das Client-Modem, und fahren Sie zuerst mit den Client-Seiten fort. Selbst wenn die abrupten Verwerfungen nur für jeden getesteten Client auftreten, reicht diese Tatsache allein nicht aus, um festzustellen, was genau dazu führt, dass sich alle vom Zugriffsserver trennen. Wenn die Untersuchungsergebnisse weitere Unterstützung von Cisco erfordern, dokumentieren Sie Ihre Ergebnisse und eröffnen Sie ein Ticket beim Cisco TAC.
Um festzustellen, ob die CSR-Werte hoch oder niedrig sind, benötigen Sie für den Bereich typische Referenzzahlen. Ziel ist es, eine CSR von 95 Prozent zu erreichen. In einer ISP-Umgebung mit einer Vielzahl von Client-Modems und einer großen Bandbreite an Bedingungen für die lokale Schleife ist dies jedoch ein schwer zu erreichendes Ziel. Da es sich bei der CSR-Funktion um ein komplexes Problem handelt, ist es schwierig, die erwarteten Erfolgsquoten bei Anrufen anzugeben. Dies ist auf die verschiedenen Bedingungen zurückzuführen, die sich auf ein Modem-Gespräch auswirken. Beispiel:
Welche Switch-Typen werden verwendet?
Verwendet der Standort Tandem-COs?
Wurden die Posten qualifiziert (BERT-Tests usw.), um sicherzustellen, dass sie sauber sind?
Wie sind Qualität und Integrität der Kupferkabelanlage?
Umfasst die Anruftopologie analoge Hops?
Werden im Netzwerk Kanalbanken oder SLIC-Karten verwendet?
Sind die Leitungen ISDN PRI oder kanalisiertes E1?
Wie werden Client-Modems verteilt?
Hinweis: Dies sind nur einige der Faktoren.
Die Statistiken müssen repräsentativ sein. Pro Modem müssen mindestens zehn Anrufe eingehen, um erste Schlüsse zu ziehen. Es wird jedoch generell empfohlen, bis einige Tausend Anrufe eingehen (siehe Hinweis 1). Jede Modemverbindung ist eindeutig. Zwei Anrufe vom gleichen Modem zur gleichen Zielnummer führen möglicherweise zwei völlig unterschiedliche Pfade über das PSTN-Netzwerk und enden möglicherweise auf unterschiedlichen physischen Host-Modems. Der Teilnehmeranschluss, die Kupferverbindung vom Kundenstandort zum Ortsgespräch, kann unter für diesen Kunden spezifischen Umweltbedingungen leiden, obwohl die meisten Anbieter von Teilnehmeranschlüssen versuchen, sicherzustellen, dass das für den Teilnehmeranschluss charakteristische Merkmal innerhalb eines zulässigen Bereichs liegt. Client-Modems verwenden unterschiedliche Chipsätze, die von Hersteller zu Hersteller variieren und häufig innerhalb der Produktlinien desselben Herstellers liegen.
Die folgenden Parameter sollten überwacht werden:
CSR: Modemübersicht anzeigen
Verbindungsgeschwindigkeiten: Modem-Verbindungsgeschwindigkeiten anzeigen, Modemprotokoll (MICA) anzeigen oder Portmodemprotokoll anzeigen (NextPort)
Signal-Rausch-Verhältnis (SNR): show modem Operational Status (MICA, NextPort), AT@E1 (Microcom), show modem log (MICA) oder show port modem log (NextPort)
Übertragungs- und Empfangsstufen: show modem Operational Status (MICA, NextPort), AT@E1 (Microcom)
Modemmodule und Protokolle: Modemprotokoll anzeigen (MICA) oder Portmodemprotokoll anzeigen (NextPort)
Modem-Trennungsgründe: Anrufstatus des Modems anzeigen
Rücksendungen und EC-Block-Neuübertragungen: Modemprotokoll (MICA) oder Portmodemprotokoll (NextPort) anzeigen, Betriebsstatus des Modems (MICA, NextPort)
Weitere Informationen finden Sie unter Übersicht über die allgemeine Modem- und NAS-Leitungsqualität und diesem Versionshinweis.
Es ist akzeptabel, dass der CSR, der von Cisco Access-Servern gemeldet wurde, um ein paar Prozent niedriger ist als der CSR, der von Access-Servern von Drittanbietern gemeldet wurde, da diese die Anrufe für erfolgreich halten. Bei Cisco Access-Servern wird der Anruf nur dann als erfolgreich markiert, wenn er sowohl die Anfangs- als auch die EC-Verhandlungsphase erfolgreich durchläuft (es sei denn, die EC-Vereinbarung wird ausgehandelt, die Benutzerdaten können nicht über die Verbindung weitergegeben werden). Drittanbieter-Zugriffsserver betrachten den Anruf in der Regel unmittelbar nach dem Abschluss des ersten Zuges als erfolgreich (d. h., es werden keine EC-Ausfälle berücksichtigt).
Das niedrige CSR-Problem kann gleichermaßen auf die Telco, die Clients oder den Zugriffsserver zurückgeführt werden. Versuchen Sie, die CSR durch Feineinstellung von Modems zu verbessern. Informationen zur Fehlerbehebung bei Modems und dem Telco-System finden Sie im Abschnitt zur Fehlerbehebung bei Client-Modems. Diese Symptome sind typisch für Probleme mit dem Zugriffsserver:
show modem meldet Cluster mit einem, zwei, drei, sechs oder zwölf Modems innerhalb derselben Modemkarte, die ungewöhnlich viele fehlgeschlagene oder "No Answer"-Anrufe aufweisen.
show modemcall-stats meldet Cluster mit einem, zwei, drei, sechs oder zwölf Modems innerhalb derselben Karte, deren Rabatte mehr als zehn Prozent auf Spalten zurückgehen als dtrDrop oder hostDrop und rmtLink (lostCarr kann auch eine gute Trennung zählen, wenn die Client-Modems LAP-M nicht beenden, bevor sie die Verbindung trennen);
Cluster mit einem, zwei, drei, sechs oder zwölf Modems auf derselben Modemkarte sind als fehlerhaft gekennzeichnet, können jedoch nach dem erneuten Laden der Firmware Anrufe entgegennehmen.
Wenn die Symptome übereinstimmen, aktualisieren Sie die Software, und konfigurieren Sie die automatische Wiederherstellung des Modems. Weitere Informationen finden Sie unter MICA und NextPort Modems.
Verwenden Sie zur Automatisierung der Analyse von Modemstatistiken die Tools , die im Rahmen der Cisco-Centric Open Source Initiative (COSI) verfügbar sind.
Verwenden Sie zur Automatisierung der Modemcap-Analyse die Tools , die im Rahmen der Cisco-Centric Open Source Initiative (COSI) verfügbar sind.
Die ISDN-Signalisierungsanalyse kann mithilfe der Tools automatisiert werden, die im Rahmen der Cisco-Centric Open Source Initiative (COSI) zur Verfügung stehen.
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
1.0 |
03-Sep-2006 |
Erstveröffentlichung |