Inhalt

Einführung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Konventionen

Beschreibung der PRI-Backhaul-Auflösung

Fehlerbehebung

Schritt 1: Überprüfen Sie die Konfiguration des Cisco Gateways AS5xx0.

Schritt 2: Überprüfen der PGW 2200-Konfiguration

Schritt 3: Überprüfen Sie die Verbindung zwischen RUDPV1 und Session Manager zwischen dem AS5xx0 und dem PGW 2200.

Schritt 4: Überprüfen Sie den Q.921-Status zwischen dem AS5xx0 und dem PABX.

Zugehörige Informationen

Einführung

Dieses Dokument unterstützt Sie bei der Fehlerbehebung für das PRI-Backhaul auf dem Cisco PGW 2200 im Anrufsteuerungsmodus. Aufgrund der Unterschiede zwischen den Protokollfamilien ist Backhauling in mehrere Kategorien unterteilt. Beispielsweise ISDN für Q Signaling (QSIG) und Digital Private Network Signaling System (DPNSS).

Dieses Dokument behandelt nur das PRI-Backhaul mit dem Cisco PGW 2200.

Voraussetzungen

Anforderungen

Die Leser dieses Dokuments sollten folgende Themen kennen:

- Cisco Media Gateway Controller Software, Version 9

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf den Cisco PGW 2200 Software-Versionen 9.3(2) und höher.

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.

Konventionen

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

Beschreibung der PRI-Backhaul-Auflösung

PRI/Q.931-Signalisierungs-Backhaul ist die Fähigkeit, die Signalisierung (Ebene Q.931 und höher) zuverlässig von einer PRI-Hauptleitung zu transportieren (siehe Abbildung 1). Dieser PRI-Trunk ist physisch mit einem Media Gateway verbunden, das zur Verarbeitung mit einem Media Gateway Controller (MGC - Cisco PGW 2200) verbunden ist. Das Signalisierungs-Backhaul für ISDN PRI erfolgt an der Layer-2- (Q.921) und Layer-3-Grenze (Q.931). Die unteren Protokollschichten werden auf dem Media Gateway (AS5xx0) terminiert und verarbeitet, während die oberen Schichten per Backhauling zum Cisco PGW 2200 transportiert werden.

Die oberen Protokollschichten werden mithilfe von Reliable User Datagram Protocol (RUDP) over IP per Backhauling oder mithilfe von RUDP an den Cisco PGW 2200 übertragen. RUDP ermöglicht die eigenständige Benachrichtigung über angeschlossene und fehlgeschlagene Sitzungen sowie die sequenzielle Bereitstellung von Signalisierungsprotokollen in einem IP-Netzwerk. Backhaul Session Manager ist eine Softwarefunktion auf dem Cisco PGW 2200 und Media Gateway, die RUDP-Sitzungen verwaltet. Signalisierungs-Backhaul bietet den zusätzlichen Vorteil der Verarbeitung verteilter Protokolle. Dies ermöglicht eine höhere Erweiterbarkeit und Skalierbarkeit. Außerdem wird die Protokollverarbeitung auf niedrigerem Layer vom Cisco PGW 2200 entlastet. Vom Layer-Modell wird das PRI-Backhaul in IP/UDP/RUDP/Backhaul-Session-Manager/PRI ISDN Layer 3 integriert.

Abbildung 1: PRI-Backhaul

Abbildung 2: PRI-Backhaul - Anrufeinrichtungssequenz

Abbildung 3: PRI-Backhaul - Anrufeinrichtungssequenz

Abbildung 4: PRI-Backhaul - Löschen des Anrufs

Fehlerbehebung

Führen Sie diese Schritte aus, um eine Fehlerbehebung für PRI-Backhaul durchzuführen.

- Schritt 1: Überprüfen Sie die Konfiguration des Cisco Gateways AS5xx0.

- Schritt 2: Überprüfen Sie die Konfiguration des Cisco PGW 2200.

- Schritt 3: Überprüfen Sie den Link Session Manager zwischen dem Cisco AS5xx0 und dem Cisco PGW 2200.

- Schritt 4: Überprüfen Sie den Q.921-Status zwischen dem AS5400 und dem PABX.

Schritt 1: Überprüfen Sie die Konfiguration des Cisco Gateways AS5xx0.

Führen Sie diese Schritte aus, um die Gateway-Konfiguration zu überprüfen.

1. Führen Sie diese Befehle im globalen Konfigurationsmodus aus, um den Backhauling Session Manager so einzurichten, dass er mit dem Cisco PGW 2200 spricht, wenn Sie die IOS®-Fehlermeldung % BSM erhalten: Die Sitzung wird nicht erstellt, die maximale Grenze wird überschritten. Sie können maximal 16 Sitzungen im IOS-Gateway 5xx0 unterstützen.

backhaul-session-manager

set set1

group group1 set set1

session group group1 x.x.x.x x.x.x.x port priority

Diese Befehlsausgabe zeigt ein Beispiel:

backhaul-session-manager

set pgw-cag client nft

group pgw-cag set pgw-cag

session group pgw-cag 213.254.253.140 6000 213.254.252.5 6000 1

session group pgw-cag 213.254.253.141 6000 213.254.252.5 6000 2

session group pgw-cag 213.254.253.156 6000 213.254.252.21 6000 3

session group pgw-cag 213.254.253.157 6000 213.254.252.21 6000 4

Hinweis: Die Cisco IOS-Konfiguration wird nicht unterstützt, wenn Sie die Backhaul Session Manager-Konfiguration verwenden, um Sitzungen abzuhalten, die auf einen anderen physischen PGW 2200 unter derselben Gruppe verweisen. Sie müssen die beiden PGWs der Serie 2200 in zwei Gruppen unterteilen. Weitere Informationen finden Sie unter Cisco Bug ID CSCec24132 .

2. Geben Sie den Befehl pri-group timeslots 1-31 service mgcp ein, um den Controller für das PRI-Backhauling unter der Controller-Konfiguration einzurichten.

Beispiel:

controller E1 7/5

pri-group timeslots 1-31 service mgcp

Hinweis: In diesem Konfigurationsbeispiel wird der Controller E1 7/5 verwendet, der zu einem späteren Zeitpunkt die Konfiguration des Cisco PGW 2200 wiedergibt.

3. Fügen Sie den Befehl isdn bind-l3 backhaul xxxx unter der ISDN D-Channel-Konfiguration ein, um eine Verbindung zur ISDN-Layer-2-Schnittstelle mit dem Backhauling-Sitzungsverwalter herzustellen.

Beispiel:

!

interface Serial7/5:15

no ip address

isdn switch-type primary-net5

isdn protocol-emulate network

isdn incoming-voice modem

isdn bind-l3 backhaul pgw-cag

isdn PROGRESS-instead-of-ALERTING

no isdn outgoing display-ie

isdn outgoing ie redirecting-number

isdn incoming alerting add-PI

no cdp enable

Hinweis: Wenn Sie den Ursachencode 41 "isdn negotiation-bchan resend-setup" hinzufügen, gilt dieser nur für ausgehende Anrufe und nicht für Anrufe, die vom Router empfangen werden. Diese CLI sendet die Konfiguration ohne die EXCLUSIVE-Anzeige und ermöglicht dem Switch, einen anderen B-Kanal auszuwählen, falls dieser verfügbar ist. Andernfalls wählt der Router, wenn der Switch mit Ursachencode 41 antwortet, einen anderen B-Kanal aus und sendet das Setup erneut.

Hinweis: Möglicherweise verfügt der Switch nicht über einen B-Kanal, der den Merkmalen in der Setup-Meldung entspricht. In diesem Fall kann der Switch keinen weiteren B-Kanal zuweisen, und auch eine Konfiguration mit einem anderen bevorzugten B-Kanal schlägt fehl.

Hinweis: Sie können MGCP-NAS und PRI-Backhaul auf dem Controller immer noch nicht gleichzeitig verwenden. Der Befehl extsig mgcp auf dem E1-Controller (erforderlich für MGCP-NAS) verhindert die Konfiguration der PRI-Gruppe auf dem Controller:

as5400(config)#contro e1 7/0

as5400(config-controller)#extsig mgcp

as5400(config-controller)#pri-group service mgcp

%Default time-slot= 16 in use

4. Führen Sie den Befehl debug backhaul-session-manager aus, um den Backhauling Session Manager zu debuggen.

Schritt 2: Überprüfen der PGW 2200-Konfiguration

Führen Sie diese Schritte aus, um die PGW 2200-Konfiguration zu überprüfen.

1. Fügen Sie IPFASPATH zur Cisco PGW 2200-Konfiguration hinzu.

prov-add:IPFASPATH:NAME="pri2-sig",DESC="Signalling PRI2

withCommunicationNAS02",EXTNODE="NAS02",MDO="ETS_300_102",

CUSTGRPID="Cisco1",SIDE="network",ABFLAG="n",CRLEN=2

Dadurch wird sichergestellt, dass die MDO-Variante der IOS-Gateway-Variante entspricht.

Hinweis: Überprüfen Sie die in dieser Tabelle enthaltene ISDN-Variante.

2. Fügen Sie DCHAN zur Cisco PGW 2200-Konfiguration hinzu.

prov-add:DCHAN:NAME="pri2-dch1",DESC="Dchannel PRI2 to

Project Communication",SVC="pri2-sig",PRI=1,SESSIONSET=

"mil1-pri2-ses",SIGSLOT=7,SIGPORT=5

Dadurch wird sichergestellt, dass SigSlot/SigPort angegeben werden. Außerdem wird sichergestellt, dass die Cisco Gateway-Ports/-Steckplätze und die Cisco PGW 2200-Ports im DCHAN übereinstimmen.

Hinweis: Wenn Sie den E1 7/5-Controller auf dem IOS-Gateway verwenden, der den Befehl isdn bind-l3 backhaul IOS enthält, muss SIGSLOT=7,SIGPORT=5 für den MML DCHAN-Befehl dieselben Informationen enthalten.

3. Stellen Sie bei der Bereitstellung der Switch-Trunks sicher, dass Sie den span-Parameter nicht als '0' eingeben. Sie können dies aus dem Inhalt der dritten Spalte in der Datei export_trunk.dat sehen.

Der span-Wert muss für die Switch-Trunks 'ffff' sein. Geben Sie den Befehl prov-exp:all:dirname="file_name" in der MML-Befehlszeile ein, um das auszuchecken.

mgcusr@pgw2200-1% mml

Copyright © 1998-2002, Cisco Systems, Inc.

Session 1 is in use, using session 2

pgw2200-1mml> prov-exp:all:dirname="check1"

MGC-01 - Media Gateway Controller 2005-08-12 17:39:44.209 MEST

M  RTRV

"ALL"

;

pgw2200-1 mml> quit

Öffnen Sie das Verzeichnis /opt/CiscoMGC/etc/cust_specific/check1. Stellen Sie in der Datei export_trunk.dat sicher, dass die dritte Spalte "ffff" anstelle von Nullen (0) enthält. Ist dies nicht der Fall, bearbeiten Sie die Datei und ändern Sie sie.

4. Führen Sie den Befehl prov-add:files:name="BCFile",file="export_trunk.dat",action="Import" aus, um eine MML-Bereitstellungssitzung zu starten, und importieren Sie die Trunks-Datei erneut.

Die geänderte Datei export_trunk.dat muss sich im Verzeichnis /opt/CiscoMGC/etc/cust_specific/check1 befinden. Denken Sie daran, eine prov-cpy für die neue Konfiguration auszugeben.

5. Geben Sie den MML-Befehl rtrv-alms ein, um die Art des Fehlers zu erklären, der derzeit auftritt.

rtrv-dest:all

!--- Shows the MGCP connectivity status of nodes !--- that the PGW 2200 defines.

rtrv-dchan:all

!--- On the active PGW 2200, the status is !--- pri-1:ipfas-1,LID=0:IS. On the standby PGW 2200, !--- the status is pri-1:ipfas-1,LID=0:OOS,STBY.

rtrv-iplnk:all

!--- All of the iplnk are on the standby PGW 2200 in the !--- iplnk-1:OOS,STBY status. They are actually in !--- the OOS state because no message is handled by them. !--- On the active PGW 2200, you see the status as iplnk-1:IS. !--- The other statuses are explained in the !--- MML Command Reference Chapter of the Cisco MGC Software !--- MML Command Reference Guide.

rtrv-tc:all

!--- Shows the status of all call channels.

rtrv-alms::cont

!--- Check the Alarms status on the Cisco PGW 2200.

Sie können die Details auch aus /opt/CiscoMGC/var/log für die Datei alm.csv abrufen, indem Sie den Befehl perl - perl -F, -anwe'print unpack("x4 A15", localtime($F[1]))," verwenden.$F[2]: @F[0,3..7]"' < meas.csv.

Hinweis: Verwenden Sie gmtime anstelle von localtime, wenn Sie in UTC-Zeitstempel konvertieren möchten. Die Ausgabe hat folgendes Format:

Aug 10 15:58:53.946: 0 0 1 "Fail to communicate with peer module

over link B" "ipAddrPeerB" "ProvObjManagement"

Aug 10 21:29:30.934: 0 1 1 "Provisioning: Dynamic Reconfiguration"

"POM-01" "ProvObjManagement"

Aug 10 21:29:48.990: 0 1 2 "Signal Channel Failure" "c7iplnk1-ls-stp1" "IosChanMgr"

Aug 10 21:29:49.620: 0 0 2 "Non-specific Failure" "ls-stp1" "IosChanMgr"

Aug 10 21:29:49.620: 0 0 2 "Signal Channel Failure" "c7iplnk1-ls-stp1" "IosChanMgr"

Aug 10 21:29:49.630: 0 0 2 "SS7 Signaling Service Unavailable" "srv-bru8" "IosChanMgr"

6. Geben Sie den UNIX-Befehl tail -f platform.log ein, um platform.log im Verzeichnis /opt/CiscoMGC/var/log zu überprüfen.

Weitere Informationen finden Sie unter Protokollmeldungen.

7. Überprüfen Sie die ISDN-Variante.

Der Befehl isdn-switch-type primary-net5 wird auf dem IOS-Gateway verwendet. Beim Cisco PGW 2200 ist er mit mdo=ETS_300_102 im IPFASPATH verknüpft.

In dieser Tabelle sind die unterstützten ISDN-Varianten für den Cisco PGW 2200 aufgeführt:

Variantenname

ISDNPRI

Spezifikation

Anmerkungen

ETS_300_102

ISDNPRI

ETSI 300_102

ETSI PRI

ETS_300_102_C2

ISDNPRI

ETSI 300_102

ETSI PRI

ATT_41459

ISDNPRI

AT&T 41459

ATT ISDN PRI

ATT_41459_C2

ISDNPRI

(Nortel Meridian)

Cisco AT&T PRI

ETS_300_172

ISDNPRI

ETSI 300-172

ETSI-QSIG

Q931_AUSTRALIEN

ISDNPRI

Frage 931

Australien PRI

Frage 931

ISDNPRI

Frage 931

Frage 931

Q931_SINGAPUR

ISDNPRI

Frage 931

Singapur PRI

Diese Beispielbefehlsausgabe stammt vom IOS-Gateway.

v5350-3(config)#isdn switch-type ?

primary-4ess    Lucent 4ESS switch type for the U.S.

primary-5ess    Lucent 5ESS switch type for the U.S.

primary-dms100  Northern Telecom DMS-100 switch type for U.S.

primary-net5    NET5 switch type for UK, Europe, Asia , Australia

primary-ni      National ISDN Switch type for the U.S.

primary-ntt     NTT switch type for Japan

primary-qsig    QSIG switch type

primary-ts014   TS014 switch type for Australia (obsolete)

v5350-3(config)#

Schritt 3: Überprüfen Sie die Verbindung zwischen RUDPV1 und Session Manager zwischen dem AS5xx0 und dem PGW 2200.

Führen Sie diese Schritte aus, um den Link RUDPV1 und Session Manager zu überprüfen.

1. Geben Sie die folgenden show- und clear-Befehle ein:

- show rudpv1 failure - Zeigt alle Fehler an, die rudpv1 erkannt hat. Sie sehen z. B. SendWindowFullFailures. Dies weist darauf hin, dass Überlastungen beim Senden von Segmenten an die IP-Verbindung auftreten.

- show rudpv1 parameters: Zeigt die rudpv1-Verbindungsparameter sowie den Status und die Parameter aller aktuellen Sitzungen an. Der Verbindungstyp ist entweder AKTIV oder PASSIVE. Active gibt an, dass dieser Peer der Client war und die Verbindung initiiert hat. Passive gibt an, dass dieser Peer der Server war und die Verbindung überwacht hat.

- show rudpv1 statistics - Zeigt interne Statistiken von rudpv1 und Statistiken für alle aktuellen Sitzungen und die kumulierten Statistiken über alle rudp-Verbindungen seit dem letzten Neustart des Felds oder der Ausführung eines klaren Statistikbefehls an.

- clear rudpv1 statistics: Löscht alle gesammelten rudpv1-Statistiken. Führen Sie diesen Befehl aus, wenn aktuelle Statistiken erforderlich sind und das IOS-Gateway über einen längeren Zeitraum ausgeführt wird.

2. Geben Sie den Befehl debug rudpv1 aus.

#debug rudpv1 ?

application  Enable application debugging

client       Create client test process

performance  Enable performance debugging

retransmit   Enable retransmit/softreset debugging

segment      Enable segment debugging

server       Create server test process

signal       Show signals sent to applications

state        Show state transitions

timer        Enable timer debugging

transfer     Show transfer state information

In einem Live-System sind die Debug für Leistung, Zustand, Signal und Übertragung die nützlichsten. Die Debugger für Anwendung, Neuübertragung und Timer generieren entweder zu viel Ausgabe und führen zum Ausfall der Links, oder sie waren nur für interne Debugzwecke nützlich.

Vorsicht: Bei diesem Debugging wird für jedes gesendete oder empfangene Segment eine Zeile ausgegeben. Wenn ein erheblicher Teil des Datenverkehrs ausgeführt wird, führt dies zu Zeitverzögerungen, die Verbindungsausfälle verursachen.

3. Geben Sie den Befehl show backhaul-session-manager und show backhaul set all befehls ein, um festzustellen, ob die IP-Leitung, die die Signalisierung transportiert, in Ordnung ist.

NAS02#show backhaul-session-manager group status all

Session-Group

Group Name   : pgw-cag

Set Name     : pgw-cag

Status       : Group-Inservice

Status (use) : Group-Active

NAS02#show backhaul  set all

Session-Set

Name   : pgw-cag

State  : BSM_SET_ACTIVE_IS

Mode   : Non-Fault-Tolerant(NFT)

Option : Option-Client

Groups : 1

statistics

Successful switchovers:0

Switchover Failures: 0

Set Down Count 1

Group: pgw-cag

Die verschiedenen Status für den Show Backhaul-Satz lauten wie folgt:

- BSM_SET_IDLE

- BSM_SET_OOS

- BSM_SET_STDBY_IS

- BSM_SET_ACTIVE_IS

- BSM_SET_FULL_IS

- BSM_SET_SWITCH_OVER

- BSM_SET_UNKNOWN

Wenn alles in Ordnung ist, bestätigt dies auch, dass die entsprechende Verbindung für den Sitzungssatz auf dem Cisco PGW 2200 über den In-Service-Status verfügt (MML-Befehl rtrv-iplnk). Die Leitung zwischen dem Cisco PGW 2200 und dem IOS-Gateway AC5xx0 ist nun voll betriebsbereit. Im nächsten Schritt wird die Grenze zwischen dem Cisco IOS-Gateway AS5xx0 und dem PABX überprüft.

Schritt 4: Überprüfen Sie den Q.921-Status zwischen dem AS5xx0 und dem PABX.

Führen Sie diese Schritte aus, um den Q.921-Status zwischen dem AS5xx0 und dem PABX zu überprüfen.

1. Geben Sie den show isdn status und die show isdn service-Befehle ein.

NAS02#show isdn status

Global ISDN Switchtype = primary-net5

ISDN Serial7/5:15 interface

******* Network side configuration *******

dsl 0, interface ISDN Switchtype = primary-net5

L2 Protocol = Q.921  L3 Protocol(s) = BACKHAUL

Layer 1 Status:

ACTIVE

Layer 2 Status:

TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED

Layer 3 Status:

0 Active Layer 3 Call(s)

Active dsl 0 CCBs = 0

The Free Channel Mask:  0xFFFF7FFF

Number of L2 Discards = 4, L2 Session ID = 25

Total Allocated ISDN CCBs = 0

NAS02#show isdn service

PRI Channel Statistics:

ISDN Se7/5:15, Channel [1-31]

Configured Isdn Interface (dsl) 0

Channel State (0=Idle 1=Proposed 2=Busy 3=Reserved 4=Restart 5=Maint_Pend)

Channel :  1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

State   :  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Service State (0=Inservice 1=Maint 2=Outofservice)

Channel :  1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

State   :  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Hier sehen Sie das Problem, dass auf der PGW 2200-Seite Q.921 nicht angezeigt wird, das dem Ziel und dem D-Kanal entspricht, der sich im Out-of-Service-Zustand befindet. Die erste Möglichkeit besteht in einer Diskrepanz in der Konfiguration auf Netzwerkseite des Q.921. Es ist einfach zu erkennen, dass dies nicht die Ursache des Problems ist, da das Problem nicht durch das Entfernen des isdn-protokollemulierten Netzwerks aus der AS5400-Konfiguration gelöst wurde.

2. Sehen Sie sich die Q.921-Debuggen an, um zu erfahren, warum der Q.921-Link nicht angezeigt wird. Dies ist die Debug-Ausgabe.

Apr 14 10:57:23.600: ISDN Se7/5:15 Q921: Net TX -> SABMEp sapi=0 tei=0

Apr 14 10:57:24.600: ISDN Se7/5:15 Q921: Net TX -> SABMEp sapi=0 tei=0

Apr 14 10:57:25.600: ISDN Se7/5:15 Q921: Net TX -> SABMEp sapi=0 tei=0

Apr 14 10:57:45.419: ISDN Se7/5:15 Q921: Net RX <- BAD FRAME(0x02017F)

Apr 14 10:57:46.419: ISDN Se7/5:15 Q921: Net RX <- BAD FRAME(0x02017F)

Das AS5400 überträgt ein Q.921 SABME, um die Verbindung zu initialisieren, und empfängt einen Frame, den es nicht interpretieren konnte (schlechter Frame). Die Möglichkeiten sind:

- Hardwareproblem auf dem E1 für diesen AS5400.

- E1-Schleife auf der Remote-Seite.

- Hardware- oder Konfigurationsprobleme auf der Remote-Seite.

Diese erste Möglichkeit wird ausgeschlossen, indem die Konfiguration auf ein anderes nicht verwendetes E1 auf demselben AS5400 verschoben wird. Das Problem sieht genau gleich aus. Der Kunde überprüft auch, ob an der E1-Leitung keine Schleife vorhanden ist. Überprüfen Sie an diesem Punkt die PABX-Seite.

3. Führen Sie den Befehl show controller aus, um mögliche Layer-1-Fehler zu überprüfen.

#show controllers E1

Framing is CRC4, Line Code is HDB3, Clock Source is Line.

Data in current interval (480 seconds elapsed):

107543277 Line Code Violations, 0 Path Code Violations

120 Slip Secs, 480 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins

0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 480 Unavail Secs

Total Data (last 24 hours)

3630889 Line Code Violations, 4097 Path Code Violations,

2345 Slip Secs, 86316 Fr Loss Secs, 20980 Line Err Secs, 0 Degraded Mins,

1 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 86317 Unavail Secs

4. Wenn Sie den Befehl shutdown unter dem Controller ausführen, wird folgende Debugmeldung ausgegeben:

000046: Jun 2 16:19:16.740: %CSM-5-PRI: delete PRI at slot 7, unit 2, channel 0

000047: Jun  2 16:19:16.744: %CONTROLLER-5-UPDOWN: Controller E1 7/2, changed sn

000048: Jun  2 16:19:16.744: SESSION: PKT: xmt. (34) bufp: 0x6367F52C, len: 16

Geben Sie den MML-Befehl rtrv-alms auf dem PGW 2200 aus:

mml> rtrv-alms

MGC-02 - Media Gateway Controller 2005-06-02 18:11:29.285 GMT

M  RTRV                                                                                                                                                                                                                            "pri-bucegi: 2005-06-02 17:28:15.301 GMT,ALM=\"FAIL\",SEV=MJ"

Wenn Sie den Befehl no shutdown unter dem Controller ausführen, wird diese Debug-Meldung im IOS-Gateway angezeigt:

000138: Jun  2 17:03:25.350: %CONTROLLER-5-UPDOWN: Controller E1 7/2, changed sp

000139: Jun  2 17:03:25.350: %CSM-5-PRI: add PRI at slot 7, unit 2, channel 15 0

Weitere IOS-Debug-Befehle finden Sie unter PRI/Q.931 Signaling Backhaul für Call Agent-Anwendungen.

Zugehörige Informationen

- Cisco PGW 2200 Softswitch - Technische Hinweise

- Technische Dokumentation für Cisco Signaling Controller

- Unterstützung von Sprachtechnologie

- Produkt-Support für Sprach- und IP-Kommunikation

- Fehlerbehebung bei Cisco IP-Telefonie

- Technischer Support und Dokumentation - Cisco Systems