Inhoud

Inleiding

Voorwaarden

Vereisten

Gebruikte componenten

Geschiedenis

Conventies

Cisco IOS DDR start de oproep

De oproep plaatsen

Extern asynchrone modem, DDR

CAS T1/E1 asynchrone modem, DDR

PRI asynchrone modem, DDR

BRI asynchrone modem, DDR

PRI ISDN DDR

BRI ISDN DDR

Gerelateerde informatie

Inleiding

Dit document bevat methoden om problemen op te lossen met verschillende typen kiesverbindingen en is niet bedoeld om te worden gelezen van begin tot eind. De structuur is zo ontworpen dat de lezer naar de belangengroepen overslaat, die elk variaties hebben op het algemene thema Problemen oplossen voor een specifiek geval.

Voorwaarden

Vereisten

Dit document bestrijkt drie hoofdscenario's. Voordat u met de probleemoplossing begint, moet u bepalen welk type oproepen wordt geprobeerd en moet u naar die sectie gaan:

- bellen

- Cisco IOS inbel-op-demand routing (DDR)

- Uitgeschakeld niet-DDR

Gebruikte componenten

Dit document is niet beperkt tot specifieke software- en hardware-versies.

De informatie in dit document is gebaseerd op apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als u in een levend netwerk werkt, zorg er dan voor dat u de potentiële impact van om het even welke opdracht begrijpt alvorens het te gebruiken.

Geschiedenis

Dialup is simpelweg de toepassing van het openbare geschakelde telefoonnetwerk (PSTN) dat gegevens voor rekening van de eindgebruiker draagt. Het betreft een CPE-apparaat (Customer Place Equipment) dat de telefoon naar de switch stuurt, dat een telefoonnummer stuurt om een verbinding te leiden. De AS3600, AS5200, AS5300, en AS5800 zijn allemaal voorbeelden van routers die de mogelijkheid hebben om een Primaire Rate Interface (PRI) samen met banken van digitale modems te gebruiken. Aan de andere kant is de AS2511 een voorbeeld van een router die met externe modems communiceert.

De transportmarkt is aanzienlijk gegroeid en de markt heeft nu hogere modemdichtheid nodig. Het antwoord op deze behoefte is een hogere mate van samenwerking met de apparatuur van telefoonmaatschappijen en de ontwikkeling van de digitale modem. Dit is een modem die digitale toegang tot de PSTN kan leiden. Als resultaat hiervan zijn er nu snellere CPE-modems ontwikkeld die gebruik maken van de helderheid van een signaal die de digitale modems genieten. Het feit dat de digitale modems die via een PRI of Basic Rate Interface (BRI) met de PSTN verbinden gegevens via meer dan 53k kunnen verzenden met behulp van de V.90 communicatie-standaard bewijst het succes van het idee.

De eerste toegangsservers waren de AS2509 en AS2511. De AS2509 kon 8 inkomende verbindingen ondersteunen met behulp van externe modems, en de AS2511 kon 16 ondersteunen. De AS5200 werd geïntroduceerd met 2 PRI's en kon 48 gebruikers ondersteunen die gebruik maakten van digitale modems, en het vertegenwoordigde technologische vooruitgang . De modemdichtheid is gestaag toegenomen met de AS5300 die 4 en vervolgens 8 PRIs ondersteunt. Ten slotte werd de AS5800 geïntroduceerd om te voorzien in de behoeften van installaties van de draagraketten die tientallen inkomende T1s en honderden gebruikersverbindingen moeten verwerken.

Een paar verouderde technologieën worden genoemd in een historische discussie over dialertechnologie. 56Kflex is een oudere (pre-V.90) 56k modemstandaard die is voorgesteld door Rockwell. Cisco ondersteunt versie 1.1 van de 56Kflex-standaard op zijn interne modems, maar raadt aan de CPE-modems zo snel mogelijk naar V.90 te verplaatsen. Een andere verouderde technologie is de AS5100. De AS5100 was een joint venture tussen Cisco en een modemfabrikant. De AS5100 werd gecreëerd als een manier om modemdichtheid door het gebruik van quad modemkaarten te verhogen. Er was een groep AS2511s mee gemoeid die als kaarten is ingebouwd in een backplane met quad-modemkaarten en een dubbele T1-kaart.

Conventies

Zie de Cisco Technical Tips Convention voor meer informatie over documentconventies.

Cisco IOS DDR start de oproep

Terwijl de benadering van het oplossen van problemen voor inkomende vraag bij de bodem begint, begint het oplossen van een uitgaande verbinding bij de bovenkant.

De algemene stroom redeneringen lijkt op het volgende:

1. Initieert het Dial on Demand Routing (DDR) een oproep? (Een ja-antwoord op de volgende vraag luidt als volgt.)

2. Als dit een asynchrone modem is, geven de chat scripts de verwachte opdrachten uit?

3. Komt de oproep uit bij het PSTN?

4. Beantwoord het afstandseinde de oproep?

5. Is de oproep klaar?

6. Gaat de data over de link?

7. Is de zitting ingesteld? (PPP of Terminal)

Om te zien of het dialer probeert om een vraag naar zijn verre bestemming te maken, gebruik de opdracht debug dialer gebeurtenissen. Meer gedetailleerde informatie kan van het debug dialer pakket worden verkregen, maar het debug dialer pakketopdracht is resource-intensief en moet niet worden gebruikt op een druk systeem dat meerdere dialer interfaces actief heeft.

De volgende lijn van debug dialer gebeurtenissen die worden uitgevoerd voor een IP-pakket bevat de naam van de DDR-interface en de bron- en doeladressen van het pakket:

Dialing cause: Async1: ip (s=172.16.1.111 d=172.16.2.22)

Als het verkeer geen poging om te bellen initieert, is de meest gebruikelijke reden onjuiste configuratie (een van de interessante verkeersdefinities, de status van de dialerinterface of de routing).

Tabel 1: Verkeer leidt geen kiespoging in

Mogelijke oorzaken

Aanbevolen acties

Ontbrekende of onjuiste "interessante" verkeersdefinities

1. Gebruik het bevel tonen in werking stellen-, zorg ervoor dat de interface met een dialer-group wordt gevormd en dat er een mondiaal niveau dialer-list met een overeenkomend aantal wordt gevormd.

2. Zorg ervoor dat de opdracht dialer-list is ingesteld om ofwel een volledig protocol toe te staan of om verkeer toe te staan dat een toegangslijst aanpast

3. Controleer dat de toegangslijst pakketten die over de link gaan interessant verklaart. Eén bruikbare test is om de opdracht debug ip-pakket [lijstnummer] te gebruiken met het nummer van de betreffende toegangslijst. Probeer dan te pingelen, of anders verkeer over de link te verzenden. Als de interessante verkeersfilters correct zijn gedefinieerd, ziet u de pakketten in de debug-uitvoer. Als er geen debug-uitvoer uit deze test is, komen de toegangslijst niet overeen met de pakketten.

Interfacestatus

Gebruik de opdracht tonen interfaces <interface name> om er zeker van te zijn dat de interface in de status "up/up (spoofing)" staat.

- Interface in "standby"-modus

Een andere (primaire) interface op de router is geconfigureerd om de dialerinterface als reservekopie te gebruiken. Bovendien is de primaire interface niet in een status van "down/down", wat vereist is om de dialerinterface uit de standby modus te halen. Bovendien moet een back-upvertraging worden ingesteld op de primaire interface, anders wordt de back-upinterface nooit uitgevoerd. Om te controleren of de dialer interface van "standby" naar "omhoog/omhoog (spoofing)" zal veranderen is het meestal nodig om de kabel van de primaire interface te halen. Eenvoudig het sluiten van de primaire interface met de shutdown van het configuratiecommando zal de primaire interface niet in "down/down" zetten maar in plaats daarvan "administratief omlaag"? Niet hetzelfde. Als de primaire verbinding via Frame Relay is, moet de Frame Relay-configuratie bovendien op een point-to-point seriële subinterface worden uitgevoerd en moet het telefoonbedrijf het "Active"-bit passeren. Deze praktijk wordt ook bekend als "end-to-end Local Management Interface (LMI)".

- Interface is "administratief omlaag"

De dialerinterface is ingesteld met de opdracht afsluiten. Dit is ook de standaardstatus van een interface wanneer een Cisco router voor het eerst wordt opgestart. Gebruik de opdracht voor het configureren van de interface niet om dit obstakel te verwijderen.

Onjuiste routing

Geef de exec opdracht om ip route te tonen [a.b.c.d], waar a.b.c.d het adres is van de dialer interface van de afstandsrouter. Als ip ongenummerd op de afstandsrouter wordt gebruikt, gebruik dan het adres van de interface die in de ip ongenummerd opdracht wordt genoemd. De uitvoer moet een route naar het externe adres via de dialerinterface tonen. Als er geen route is, zorg er dan voor dat statische of zwevende statische routes zijn gevormd door het uitvoeren van show in werking stellen-configuratie te onderzoeken. Als er een route via een interface anders is dan de dialer interface, is de implicatie dat DDR als back-up wordt gebruikt. Onderzoek de routerconfiguratie om ervoor te zorgen dat statische of drijvende statische routes zijn gevormd. De beste manier om het routing te testen, in dit geval, is de primaire verbinding uit te schakelen en de show ip route uit te voeren [a.b.c.d] opdracht om te controleren of de juiste route in de routingtabel is geïnstalleerd.
Opmerking: Als u dit tijdens een actief netwerk probeert, kan er een gebeurtenis met de knop worden geactiveerd. Dit soort testen kan het best worden uitgevoerd tijdens geplande onderhoudscycli.

De oproep plaatsen

Als de routing en de interessante verkeersfilters correct zijn, moet een oproep worden geïnitieerd. Dit kan worden gezien door het gebruik van debug dialer gebeurtenissen:

Async1 DDR: Dialing cause ip (s=10.0.0.1, d=10.0.0.2)

Async1 DDR: Attempting to dial 5551212

Als de draaiknop wel zichtbaar is maar er wordt niet geprobeerd te bellen, is de gebruikelijke reden een verkeerd ingesteld dialerbeeld of dialerprofiel.

Tabel 2: Bel niet op zijn plaats

Mogelijk probleem

Aanbevolen acties

Dialoogkaart verkeerd ingesteld

Gebruik de opdracht tonen in werking gesteld-klaar om te verzekeren dat de dialing interface met minstens één dialerkaart verklaring wordt gevormd die aan het protocoladres en geroepen aantal van de verre plaats wijst.

Dialoogprofiel niet goed ingesteld

Gebruik de opdracht tonen in werking stellen-configuratie om ervoor te zorgen dat de interface van de Kiezer wordt geconfigureerd met een dialer pool X-opdracht en dat een dialerinterface op de router wordt geconfigureerd met een overeenkomend dialer pool-lid X. Als dialoogvensterprofielen niet goed zijn geconfigureerd, kunt u bijvoorbeeld een debug-bericht zien:
Dialer1: Can't place call, no dialer pool set
Zorg dat een dialer string is ingesteld.

Identificeer vervolgens het type media dat wordt gebruikt:

- Externe asynchrone modem

- Channel Associated Signaling (CAS) T1/E1 asynchrone modem.

- PRI asynchrone modem, DDR

- BRI asynchrone modem DDR

- PRI ISDN DDR

- BRI ISDN DDR

Extern asynchrone modem, DDR

1. Om een externe async modem DDR te identificeren, gebruik de volgende opdrachten, dan probeer een vraag te maken:

router# debug modem

router# debug chat line

2. Voor modemoproepen moet een chatscript worden uitgevoerd zodat de oproep kan doorgaan. Voor dialer kaart-gebaseerde DDR, wordt het chat script aangehaald door de modemscript parameter in een dialer map opdracht. Als DDR op een dialerprofiel gebaseerd is, wordt dit bereikt door het dialer van het bevelschrift, gevormd op de lijn TTY. Beide methodes baseren zich op een chatscript dat in de mondiale configuratie van de router bestaat, bijvoorbeeld:

chat-script callout AT OK atdt\T TIMEOUT 60 CONNECT \c

In beide gevallen, is de opdracht om de activiteit van het chatscript te bekijken debug chat. Als de wijzerplaat (dat wil zeggen, telefoonnummer) in de dialer kaart of dialer string opdracht 5551212 gebruikte, zou de debug uitvoer als volgt eruit zien:

CHAT1: Attempting async line dialer script

CHAT1: Dialing using Modem script: callout & System script: none

CHAT1: process started

CHAT1: Asserting DTR

CHAT1: Chat script callout started

CHAT1: Sending string: AT

CHAT1: Expecting string: OK

CHAT1: Completed match for expect: OK

CHAT1: Sending string: atdt5551212

CHAT1: Expecting string: CONNECT

CHAT1: Completed match for expect: CONNECT

CHAT1: Chat script callout finished, status = Success

3. Zorg ervoor dat het chat script de verwachte aanroep (d.w.z. het juiste nummer) probeert op basis van de "Sending string." Als het chat script niet probeert de verwachte aanroep te maken, verifieert u de configuratie van het chat script. Gebruik de opdracht Start-chat om het chatscript handmatig te openen.

4. Zie "Time-out" verwacht: CONNECT" kan verschillende mogelijkheden beschrijven:

- Mogelijkheid 1: De lokale modem plaatst eigenlijk niet de vraag. Controleer dat de modem een vraag kan plaatsen door een omgekeerd telnet aan de modem uit te voeren en handmatig een wijzerplaat te openen. Als het externe gedeelte geen antwoord lijkt te geven, controleert u of de oproep door de inkomende modem wordt geplaatst door een lokaal nummer handmatig te bellen met de opdracht ATDT <number> en naar de ring te luisteren.

- Mogelijkheid 2: De modem op afstand is geen antwoord. Test dit door de afstandsmodem te bellen met een gewone POTS-telefoon. Probeer dit:

1. Zorg ervoor dat het opgeroepen telefoonnummer juist is. Gebruik een handset om het ontvangende nummer te bellen. Gebruik dezelfde kabel aan de muur die de modem gebruikte. Als een handvraag de ontvangende asynchrone modem kan bereiken, werkt de oorsprong modem misschien niet correct. Controleer de modem en vervang deze indien nodig.

2. Als een handmatige oproep niet in staat is om de antwoordasynchrone modem te bereiken, verander de telefoonkabels op de ontvangende modem en probeer een regelmatige telefoon op de lijn van de ontvangende modem. Als de oproep via de gewone telefoon kan worden ontvangen, is er waarschijnlijk een probleem met de ontvangende modem.

3. Als het handmatige gesprek nog steeds niet in staat is om de gewone telefoon op de betreffende lijn te bereiken, probeer dan een andere (bekende goede) lijn in de ontvangende faciliteit. Als dat OK verbindt, laat de telco de telefoonlijn die naar de ontvangende modem gaat controleren.

4. Als dit een langeafstandsbediening is, probeert u de oorspronkelijke kant een ander (bekend goed) langeafstandsnummer. Als dat werkt, kan de ontvangende faciliteit of lijn niet worden voorzien om lange-afstandsgesprekken te ontvangen. Als de lijn van oorsprong geen andere lange afstand getallen kan bereiken, kan deze geen lange afstand hebben geactiveerd. Probeer 1010 codes voor verschillende langeafstandsbedrijven.

5. Probeer tenslotte een ander (bekend goed) plaatselijk nummer van de oorsprong. Als de verbinding nog steeds niet is voltooid, dient de telco de oorsprong te controleren.

- Mogelijkheid 3: Het nummer dat wordt gedraaid is niet correct. Controleer het nummer door het handmatig in te stellen. Corrigeer de configuratie indien nodig.

- Mogelijkheid 4: De modemtraining duurt te lang of de TIMEOUT-waarde is te laag. Probeer de TIMEOUT waarde in de opdracht chat-script te verhogen. Als de TIMEOUT al 60 seconden of langer is, kan er een kabelprobleem zijn tussen de modem en de DTE waaraan deze is gekoppeld. Trainingsfouten kunnen ook duiden op een stroomprobleem of modemoncompatibiliteit.

Om bij de onderkant van een individueel modemprobleem te komen, gaat u naar de AT-prompt bij de oorspronkelijke modem met reverse telnet. Als het mogelijk is, stap dan ook naar de AT-prompt van de ontvangende modem. De meeste modems wijzen op een ring aan de eindsessie verbonden aan hun DTE verbinding. Gebruik ATM1 om de modem te laten om geluiden naar zijn luidspreker te sturen zodat de mensen aan elk eind kunnen horen wat op de lijn gebeurt.

Heeft de muziek geluid? Als dit het geval is, reinigt u het circuit. Als de asynchrone modems niet omhoog trainen, roep het nummer en luister naar statisch. Er kunnen andere factoren zijn die de trein bemoeilijken. Keer telnet naar de asynchrone modem en debug.

5. Als alles goed werkt en u nog steeds geen verbinding kunt maken op uw CAS async modem DDR, probeer dan PPP het zuiveren. Gebruik de opdrachten:

router# debug ppp negotiation

router# debug ppp authentication

Als het chat script klaar is, worden de modems aangesloten. Raadpleeg het gedeelte 'Problemen oplossen' in hoofdstuk 17 van de gids voor probleemoplossing op het netwerk voor de volgende stap in het oplossen van de verbinding.

CAS T1/E1 asynchrone modem, DDR

1. Om een CAS T1/E1 asynchrone modem DDR te identificeren, gebruik de volgende opdrachten dan om een vraag te maken:

Waarschuwing:  Het uitvoeren van debugs op een druk systeem zou de router kunnen crashen door de CPU te overladen of de console-buffer te overlopen!

router# debug modem

router# debug chat or debug chat line n

router# debug modem csm

router# debug cas

Opmerking: Het debug CAS-opdracht is beschikbaar op Cisco AS5200- en AS5300-platforms die Cisco IOS gebruiken?? IOS-softwarerelease 12.0(7)T en hoger. In eerdere versies van IOS, zou de interne opdrachtservice moeten worden ingevoerd op het hoofdniveau van de configuratie van de router en modemconfiguratie-mt csm debug-rbs die bij de snelle melding moeten worden ingevoerd. Het zuiveren op Cisco AS5800 vereist verbinding met de boomstamkaart. (Gebruik modemgarantie csm no-debug-rbs om het debug uit te schakelen)

2. Voor modemoproepen moet een chatscript worden uitgevoerd zodat de oproep kan doorgaan. Voor dialer kaart-gebaseerde DDR, wordt het chat script aangehaald door de modemscript parameter in een dialer map opdracht. Als DDR op een dialerprofiel gebaseerd is, wordt dit bereikt door het dialer van het bevelschrift, gevormd op de lijn TTY. Beide gebruiken baseren zich op een chatscript dat in de wereldwijde configuratie van de router bestaat, zoals:

chat-script callout AT OK atdt\T TIMEOUT 60 CONNECT \c

In beide gevallen, is de opdracht om de activiteit van het chatscript te bekijken debug chat. Als de wijzerplaat (dat wil zeggen, telefoonnummer) in de dialer kaart of dialer string opdracht 5551212 gebruikte, zou de debug uitvoer als volgt eruit zien:

CHAT1: Attempting async line dialer script

CHAT1: Dialing using Modem script: callout & System script: none

CHAT1: process started

CHAT1: Asserting DTR

CHAT1: Chat script callout started

CHAT1: Sending string: AT

CHAT1: Expecting string: OK

CHAT1: Completed match for expect: OK

CHAT1: Sending string: atdt5551212

CHAT1: Expecting string: CONNECT

CHAT1: Completed match for expect: CONNECT

CHAT1: Chat script callout finished, status = Success

3. Zorg ervoor dat het chat script de verwachte aanroep (d.w.z. het juiste nummer) probeert op basis van de "Sending string". Als het chat script niet probeert de verwachte aanroep te maken, verifieert u de configuratie van het chat script. Gebruik de opdracht Start-chat om het chatscript handmatig te openen.

4. Zie "Time-out" verwacht: CONNECT" kan verschillende mogelijkheden beschrijven:

- Mogelijkheid 1: De lokale modem plaatst eigenlijk niet de vraag. Controleer dat de modem een vraag kan plaatsen door een omgekeerde telnet aan de modem uit te voeren en handmatig een wijzerplaat kan openen. Als het afstandsbediening niet lijkt te reageren, controleert u of de oproep door de modem wordt geplaatst door handmatig een lokaal nummer te bellen met de opdracht ATDT<number> en naar de ring te luisteren.

Voor uitgaande oproepen via CAS T1 of E1 en geïntegreerde digitale modems is een groot deel van de probleemoplossing gelijk aan andere DDR-probleemoplossing. Hetzelfde geldt ook voor uitgaande geïntegreerde modemoproepen via een PRI-lijn. De unieke eigenschappen die bij het maken van een vraag op deze manier betrokken zijn vereist speciale zuivering in het geval van een vraag mislukking.

Net als bij andere DDR-situaties moet u ervoor zorgen dat er een callpoging wordt gevraagd. Gebruik debug dialer gebeurtenissen voor dit doel. Raadpleeg IOS DDR, eerder in dit artikel.

Voordat er een oproep kan worden geplaatst, moet er een modem worden toegewezen voor de oproep. Om dit proces en de daaropvolgende oproep te bekijken, gebruikt u de volgende debug-opdrachten:

router# debug modem

router# debug modem csm

router# debug cas

Opmerking: de debug cas-opdracht is eerst verschenen in IOS versie 12.0(7)T voor de AS5200 en AS5300. Eerdere versies van IOS gebruiken een interne configuratie-service op systeemniveau samen met de snelle modemmodule-mt debug rbs:

De Debugs inschakelen:

router#conf t

Enter configuration commands, one per line.  End with CNTL/Z.

router(config)#service internal

router(config)#^Z

router#modem-mgmt csm ?

debug-rbs     enable rbs debugging

no-debug-rbs  disable rbs debugging

router#modem-mgmt csm debug-rbs

router#

neat msg at slot 0: debug-rbs is on

neat msg at slot 0: special debug-rbs is on

De Debugs uitschakelen:

router#modem-mgmt csm no-debug-rbs

neat msg at slot 0: debug-rbs is off

Het afluisteren van deze informatie op een AS5800 vereist verbinding met de kofferkaart. Het volgende is een voorbeeld van een normaal uitgaande verbinding over een CAS T1 die voor FXS-Ground-Start is uitgerust en ingesteld:

Mica Modem(1/0): Rcvd Dial String(5551111)

[Modem receives digits from chat script]

CSM_PROC_IDLE: CSM_EVENT_MODEM_OFFHOOK at slot 1, port 0

CSM_RX_CAS_EVENT_FROM_NEAT:(A003):

EVENT_CHANNEL_LOCK at slot 1 and port 0

CSM_PROC_OC4_DIALING:

CSM_EVENT_DSX0_BCHAN_ASSIGNED at slot 1, port 0

Mica Modem(1/0): Configure(0x1)

Mica Modem(1/0): Configure(0x2)

Mica Modem(1/0): Configure(0x5)

Mica Modem(1/0): Call Setup

neat msg at slot 0: (0/2): Tx RING_GROUND

Mica Modem(1/0): State Transition to Call Setup

neat msg at slot 0: (0/2): Rx TIP_GROUND_NORING

[Telco switch goes OFFHOOK]

CSM_RX_CAS_EVENT_FROM_NEAT:(A003):

EVENT_START_TX_TONE at slot 1 and port 0

CSM_PROC_OC5_WAIT_FOR_CARRIER:

CSM_EVENT_DSX0_START_TX_TONE at slot 1, port 0

neat msg at slot 0: (0/2):

Tx LOOP_CLOSURE [Now the router goes OFFHOOK]

Mica Modem(1/0): Rcvd Tone detected(2)

Mica Modem(1/0): Generate digits:called_party_num=5551111 len=8

Mica Modem(1/0): Rcvd Digits Generated

CSM_PROC_OC5_WAIT_FOR_CARRIER:

CSM_EVENT_ADDR_INFO_COLLECTED at slot 1, port 0

CSM_RX_CAS_EVENT_FROM_NEAT:(A003):

EVENT_CHANNEL_CONNECTED at slot 1 and port 0

CSM_PROC_OC5_WAIT_FOR_CARRIER:

CSM_EVENT_DSX0_CONNECTED at slot 1, port 0

Mica Modem(1/0): Link Initiate

Mica Modem(1/0): State Transition to Connect

Mica Modem(1/0): State Transition to Link

Mica Modem(1/0): State Transition to Trainup

Mica Modem(1/0): State Transition to EC Negotiating

Mica Modem(1/0): State Transition to Steady State

Mica Modem(1/0): State Transition to Steady State Speedshifting

Mica Modem(1/0): State Transition to Steady State

Debugs voor T1s en E1s met andere signaleringstypes zijn vergelijkbaar.

Het bereiken van dit punt in het zuiveren wijst erop dat de het roepen en het beantwoorden van modems getraind en verbonden hebben en dat de hoger-laagprotocollen kunnen beginnen te onderhandelen. Als een modem goed toegewezen wordt voor de uitgaande vraag maar de verbinding niet zover krijgt moet T1 worden onderzocht. Gebruik de opdracht Show controller t1/e1 om te controleren of T1/E1 werkt. Zie Problemen oplossen seriële lijnen voor een verklaring van de uitvoer van de controller. Als de T1/E1 niet goed werkt, is een T1/E1-probleemoplossing nodig.

- Mogelijkheid 2: De modem op afstand is geen antwoord. Test dit door de afstandsmodem te bellen met een gewone telefoon. Probeer dit:

1. Zorg ervoor dat het opgeroepen telefoonnummer juist is. Gebruik een handset om het ontvangende nummer te bellen.

2. Zorg ervoor dat een handvraag de antwoordasynchrone modem kan bereiken. Als een handvraag de antwoordende asynchrone modem kan bereiken, kan de lijn van CAS niet voorzien worden om uitgaande spraakoproepen toe te staan.

3. Als een handmatige oproep niet in staat is om de antwoordasynchrone modem te bereiken, verander de telefoonkabels op de ontvangende modem en probeer een regelmatige telefoon op de lijn van de ontvangende modem. Als de oproep via de gewone telefoon kan worden ontvangen, is er waarschijnlijk een probleem met de ontvangende modem.

4. Als het handmatige gesprek nog steeds niet in staat is om de gewone telefoon op de betreffende lijn te bereiken, probeer dan een andere (bekende goede) lijn in de ontvangende faciliteit. Als dat verbinding maakt, moet u de telco-lijn laten controleren die naar de ontvangende modem gaat.

5. Als dit een langeafstandsbediening is, probeert u de oorspronkelijke kant een ander (bekend goed) langeafstandsnummer. Als dat werkt, kan de ontvangende faciliteit of lijn niet voorzien worden om lange-afstandsgesprekken te ontvangen. Als de lijn van oorsprong (CAS) geen andere lange afstand getallen kan bereiken, is er mogelijk geen lange afstand geactiveerd. Probeer 10-10 codes voor verschillende langeafstandsbedrijven.

6. Probeer ten slotte een ander (bekend goed) plaatselijk nummer van de oorsprong CAS-lijn. Als de verbinding nog steeds mislukt, dient u telco de CAS te controleren.

- Mogelijkheid 3: Het nummer dat wordt gedraaid is niet correct. Controleer het nummer door het handmatig in te stellen. Corrigeer de configuratie indien nodig.

- Mogelijkheid 4: De modemtraining duurt te lang of de TIMEOUT-waarde is te laag. Probeer de TIMEOUT waarde in de opdracht chat-script te verhogen. Als de TIMEOUT al 60 seconden of langer is, kan er een kabelprobleem zijn tussen de modem en de DTE waaraan deze is gekoppeld. Trainingsfouten kunnen ook duiden op een stroomprobleem of modemoncompatibiliteit.

Om bij de onderkant van een individueel modemprobleem te komen, gaat u naar de AT-prompt bij de oorspronkelijke modem met reverse telnet. Gebruik indien mogelijk ook reverse telnet om de AT-prompt van de ontvangende modem te bereiken. Gebruik ATM1 om de modem te laten om geluiden naar zijn luidspreker te sturen zodat de mensen aan elk eind kunnen horen wat op de lijn gebeurt.

Heeft de muziek geluid? Als dit het geval is, reinigt u het circuit. Als de asynchrone modems niet omhoog trainen, roep het nummer en luister naar statisch. Er kunnen andere factoren zijn die de trein bemoeilijken. Achteruit telnet naar de asynchrone modem en debug.

5. Als alles goed werkt en u nog steeds geen verbinding kunt maken op uw CAS async modem DDR, probeer dan PPP het zuiveren. Als het chat-script succesvol is voltooid en de PPP-debugs duiden op een storing, raadpleeg de sectie "Problemen oplossen PPP" in hoofdstuk 17 van de Guide voor probleemoplossing tussen netwerken.

PRI asynchrone modem, DDR

1. Om een PRI async modem DDR te identificeren, gebruik de volgende opdrachten, dan probeer een vraag te maken:

Waarschuwing:  Het uitvoeren van debugs op een druk systeem zou de router kunnen crashen door de CPU te overladen of de console-buffer te overlopen!

router# debug modem

router# debug chat

router# debug modem csm

router# debug isdn q931

router# debug isdn

router# debug ppp negotiate

router# debug ppp authenticate

2. Voor modemoproepen moet een chatscript worden uitgevoerd zodat de oproep kan doorgaan. Voor dialer kaart-gebaseerde DDR, wordt het chat script aangehaald door de modemscript parameter in een dialer map opdracht. Als DDR op een dialerprofiel gebaseerd is, wordt dit bereikt door het dialer van het bevelschrift, gevormd op de lijn TTY. Beide methodes baseren zich op een chatscript dat in de mondiale configuratie van de router bestaat, zoals:

chat-script callout AT OK atdt\T TIMEOUT 60 CONNECT \c

In beide gevallen, is de opdracht om de activiteit van het chatscript te bekijken debug chat. Als de wijzerplaat (telefoonnummer) in de dialer kaart of dialer string opdracht 5551212 was, zou de debug uitvoer als volgt eruit zien:

CHAT1: Attempting async line dialer script

CHAT1: Dialing using Modem script: callout & System script: none

CHAT1: process started

CHAT1: Asserting DTR

CHAT1: Chat script callout started

CHAT1: Sending string: AT

CHAT1: Expecting string: OK

CHAT1: Completed match for expect: OK

CHAT1: Sending string: atdt5551212

CHAT1: Expecting string: CONNECT

CHAT1: Completed match for expect: CONNECT

CHAT1: Chat script callout finished, status = Success

3. Zorg ervoor dat het chat script de verwachte aanroep (het juiste nummer) probeert op basis van de "Sending string." Als het chat script niet probeert de verwachte aanroep te maken, verifieert u de configuratie van het chat script. Gebruik de opdracht Start-chat om het chatscript handmatig te openen.

4. Zie "Time-out" verwacht: CONNECT" kan verschillende mogelijkheden beschrijven:

- Mogelijkheid 1: De lokale modem plaatst eigenlijk niet de vraag. Controleer dat de modem een vraag kan plaatsen door een omgekeerd telnet aan de modem uit te voeren en handmatig een wijzerplaat te openen. Als het externe gedeelte geen antwoord lijkt te geven, controleert u of de oproep door de modem wordt geplaatst door een lokaal nummer handmatig te bellen met de opdracht ATDT<number> en naar de ring te luisteren. Als er geen verbinding wordt gemaakt, schakelt u ISDN-apparaten in. Na het eerste vermoeden van een mislukking van ISDN op een BRI, controleer altijd de uitvoer van show ISDN status. De belangrijkste dingen om op te merken zijn dat Layer 1 Active zou moeten zijn en Layer 2 zou in een toestand van MULTIPLE_FRAME_ESTABLISHED moeten zijn. Zie Hoofdstuk 16 van de Handleiding voor probleemoplossing van Internetwork, "Interpreting Show ISDN Status" voor informatie over het lezen van deze uitvoer, evenals voor corrigerende maatregelen.

Voor uitgaande vraag van ISDN, debug isdn q931 en debug isdn zijn de beste gereedschappen om te gebruiken. Gelukkig, het zuiveren van uitgaande oproepen is zeer gelijkaardig aan het zuiveren van inkomende oproepen. Een normale succesvolle oproep ziet er zo uit:

*Mar 20 21:07:45.025: ISDN SE0:23: Event:

Call to 5553759 at 64 Kb/s

*Mar 20 21:07:45.033: ISDN SE0:23: TX ->  SETUP pd = 8

callref = 0x2C

*Mar 20 21:07:45.037:         Bearer Capability i = 0x8890

*Mar 20 21:07:45.041:         Channel ID i = 0x83

*Mar 20 21:07:45.041:         Keypad Facility i = 0x35353533373539

*Mar 20 21:07:45.141: ISDN SE0:23: RX <-  CALL_PROC pd = 8

callref = 0xAC

*Mar 20 21:07:45.145:         Channel ID i = 0x89

*Mar 20 21:07:45.157: ISDN SE0:23: received HOST_PROCEEDING

Channel ID i = 0x0101

*Mar 20 21:07:45.161:   -------------------

Channel ID i = 0x89

*Mar 20 21:07:45.313: ISDN SE0:23: RX <-  CONNECT pd = 8

callref = 0xAC

*Mar 20 21:07:45.325: ISDN SE0:23: received HOST_CONNECT

Merk op dat het CONNECT-bericht de belangrijkste indicator voor het succes is. Als er geen CONNECT is ontvangen, ziet u een DISCONNECT of een RELEASE_COMP (release complete) bericht gevolgd door een oorzaakcode:

*Mar 20 22:11:03.212: ISDN SE0:23:

RX <-RELEASE_COMP pd = 8 callref = 0x8F

*Mar 20 22:11:03.216:         Cause i = 0x8295 - Call rejected

De waarde van de oorzaak duidt op twee dingen:

- De tweede byte van de 4- of 6-byte-waarde geeft het punt aan in het end-to-end call pad waaruit de DISCONNECT of RELEASE_COMP is ontvangen. Dit kan u helpen om het probleem te lokaliseren.

- De derde en vierde bytes geven de werkelijke reden voor de fout aan. Zie Tabel 9 voor de betekenis van de verschillende waarden.

- Mogelijkheid 2: De modem op afstand is geen antwoord. Test dit door de afstandsmodem te bellen met een gewone telefoon. Probeer dit:

1. Zorg ervoor dat het opgeroepen telefoonnummer juist is. Gebruik een handset om het ontvangende nummer te bellen.

2. Zorg ervoor dat een handvraag de antwoordasynchrone modem kan bereiken. Als een handvraag de antwoordende asynchrone modem kan bereiken, kan de lijn BRI niet voorzien worden om uitgaande spraakoproepen toe te staan.

3. Als een handmatige oproep niet in staat is om de antwoordasynchrone modem te bereiken, verander de telefoonkabels op de ontvangende modem en probeer een regelmatige telefoon op de lijn van de ontvangende modem. Als de oproep via de gewone telefoon kan worden ontvangen, is er waarschijnlijk een probleem met de ontvangende modem.

4. Als het handmatige gesprek nog steeds niet in staat is om de gewone telefoon op de betreffende lijn te bereiken, probeer dan een andere (bekende goede) lijn in de ontvangende faciliteit. Als dat verbinding maakt, moet u de telco-lijn laten controleren die naar de ontvangende modem gaat.

5. Als dit een langeafstandsbediening is, probeert u de oorspronkelijke kant een ander (bekend goed) langeafstandsnummer. Als dat werkt, kan de ontvangende faciliteit of de ontvangende lijn niet voorzien worden om lange-afstandsgesprekken te ontvangen. Als de lijn van oorsprong (BRI) geen andere lange afstand getallen kan bereiken, kan deze geen lange afstand hebben geactiveerd. Probeer 1010 codes voor verschillende langeafstandsbedrijven.

6. Probeer tenslotte een ander (bekend goed) lokaal nummer van de oorsprong BRI lijn. Als de verbinding nog steeds faalt, dient u telco de BRI te controleren.

- Mogelijkheid 3: Het nummer dat wordt gedraaid is niet correct. Controleer het nummer door het handmatig in te stellen. Corrigeer de configuratie indien nodig.

- Mogelijkheid 4: De modemtraining duurt te lang of de TIMEOUT-waarde is te laag. Probeer de TIMEOUT-waarde in de chat-script opdracht te verhogen. Als de TIMEOUT al 60 seconden of langer is, kan er een kabelprobleem zijn tussen de modem en de DTE waaraan het is gekoppeld. Trainingsfouten kunnen ook duiden op een stroomprobleem of modemoncompatibiliteit.

Om bij de onderkant van een individueel modemprobleem te komen, gaat u naar de AT-prompt bij de oorspronkelijke modem met reverse telnet. Gebruik indien mogelijk ook reverse telnet om de AT-prompt van de ontvangende modem te bereiken. Gebruik ATM1 om de modem te laten om geluiden naar zijn luidspreker te sturen zodat de mensen aan elk eind kunnen horen wat op de lijn gebeurt.

Heeft de muziek geluid? Als dit het geval is, reinigt u het circuit. Als de asynchrone modems niet omhoog trainen, roep het nummer en luister naar statisch. Er kunnen andere factoren zijn die de trein bemoeilijken. Achteruit telnet naar de asynchrone modem en debug.

5. Als alles goed werkt en u nog steeds geen verbinding kunt maken op uw BRI asynchrone modem DDR, probeer dan PPP het zuiveren. Als het chat-script succesvol is voltooid en de PPP-debugs duiden op een storing, raadpleeg dan de sectie "Problemen oplossen PPP" in hoofdstuk 17 van de Guide voor probleemoplossing tussen netwerken.

BRI asynchrone modem, DDR

Deze functie werkt alleen op het Cisco 3640-platform met behulp van Cisco IOS-softwarerelease 12.0(3)T of hoger. Het vereist een latere hardwareherziening van de BRI netwerkmodule. Dit werkt niet met een WAN-interfacekaart (WIC).

1. Zorg ervoor dat de landcode juist is met de modemopdracht van de show. Gebruik de volgende opdrachten en probeer een oproep te doen:

Waarschuwing:  Het uitvoeren van debugs op een druk systeem zou de router kunnen crashen door de CPU te overladen of de console-buffer te overlopen!

router# debug modem

router# debug chat

router# debug modem csm

router# debug isdn q931

router# debug bri

router# debug ppp negotiate

router# debug ppp authenticate

2. Voor modemoproepen moet een chatscript worden uitgevoerd zodat de oproep kan doorgaan. Voor dialer kaart-gebaseerde DDR, wordt het chat script aangehaald door de modemscript parameter in een dialer map opdracht. Als DDR op een dialerprofiel gebaseerd is, wordt dit bereikt door het dialer van het bevelschrift, gevormd op de lijn TTY. Beide gebruiken baseren zich op een chatscript dat in de wereldwijde configuratie van de router bestaat, zoals:

chat-script callout AT OK atdt\T TIMEOUT 60 CONNECT \c

In beide gevallen, is de opdracht om de activiteit van het chatscript te bekijken debug chat. Als de wijzerplaat (telefoonnummer) in de dialer kaart of dialer string opdracht 5551212 was, zou de debug uitvoer als volgt eruit zien:

CHAT1: Attempting async line dialer script

CHAT1: Dialing using Modem script: callout & System script: none

CHAT1: process started

CHAT1: Asserting DTR

CHAT1: Chat script callout started

CHAT1: Sending string: AT

CHAT1: Expecting string: OK

CHAT1: Completed match for expect: OK

CHAT1: Sending string: atdt5551212

CHAT1: Expecting string: CONNECT

CHAT1: Completed match for expect: CONNECT

CHAT1: Chat script callout finished, status = Success

3. Zorg ervoor dat het chat script de verwachte aanroep (het juiste nummer) probeert op basis van de "Sending string." Als het chat script niet probeert de verwachte aanroep te maken, verifieert u de configuratie van het chat script. Gebruik de opdracht Start-chat om het chatscript handmatig te openen.

4. Zie "Time-out" verwacht: CONNECT" kan verschillende mogelijkheden beschrijven:

- Mogelijkheid 1: De lokale modem plaatst eigenlijk niet de vraag. Controleer dat de modem een vraag kan plaatsen door een omgekeerd telnet aan de modem uit te voeren en handmatig een wijzerplaat te openen. Als het externe gedeelte geen antwoord lijkt te geven, controleert u of de oproep door de modem wordt geplaatst door een lokaal nummer handmatig te bellen met de opdracht ATDT<number> en naar de ring te luisteren. Als er geen verbinding wordt gemaakt, schakelt u ISDN-apparaten in. Na het eerste vermoeden van een mislukking van ISDN op een BRI, controleer altijd de uitvoer van show ISDN status. De belangrijkste dingen om op te merken zijn dat Layer 1 Active zou moeten zijn en Layer 2 zou in een toestand van MULTIPLE_FRAME_ESTABLISHED moeten zijn. Zie Hoofdstuk 16 van de gids voor probleemoplossing voor Internetwork, "Interpreting Show ISDN Status" voor informatie over het lezen van deze uitvoer en corrigerende maatregelen.

Voor uitgaande vraag van ISDN, debug isdn q931 en debug isdn zijn de beste gereedschappen om te gebruiken. Gelukkig, het zuiveren van uitgaande oproepen is zeer gelijkaardig aan het zuiveren van inkomende oproepen. Een normale succesvolle oproep ziet er zo uit:

*Mar 20 21:07:45.025: ISDN BR0: Event:

Call to 5553759 at 64 Kb/s

*Mar 20 21:07:45.033: ISDN BR0: TX ->  SETUP pd = 8

callref = 0x2C

*Mar 20 21:07:45.037:         Bearer Capability i = 0x8890

*Mar 20 21:07:45.041:         Channel ID i = 0x83

*Mar 20 21:07:45.041:         Keypad Facility i = 0x35353533373539

*Mar 20 21:07:45.141: ISDN BR0: RX <-  CALL_PROC pd = 8

callref = 0xAC

*Mar 20 21:07:45.145:         Channel ID i = 0x89

*Mar 20 21:07:45.157: ISDN BR0: received HOST_PROCEEDING

Channel ID i = 0x0101

*Mar 20 21:07:45.161:   -------------------

Channel ID i = 0x89

*Mar 20 21:07:45.313: ISDN BR0: RX <-  CONNECT pd = 8

callref = 0xAC

*Mar 20 21:07:45.325: ISDN BR0: received HOST_CONNECT

Merk op dat het CONNECT-bericht de belangrijkste indicator voor het succes is. Als er geen CONNECT is ontvangen, ziet u een DISCONNECT of een RELEASE_COMP (release complete) bericht gevolgd door een oorzaakcode:

*Mar 20 22:11:03.212: ISDN BR0: RX <-  RELEASE_COMP pd = 8

callref = 0x8F

*Mar 20 22:11:03.216:         Cause i = 0x8295 - Call rejected

De waarde van de oorzaak duidt op twee dingen.

- De tweede byte van de 4- of 6-byte-waarde geeft het punt aan in het end-to-end call pad waaruit de DISCONNECT of RELEASE_COMP is ontvangen. Dit kan u helpen om het probleem te lokaliseren.

- De derde en vierde bytes geven de werkelijke reden voor de fout aan. Zie Tabel 9 voor de betekenis van de verschillende waarden.

- Mogelijkheid 2: De modem op afstand is geen antwoord. Test dit door de afstandsmodem te bellen met een gewone telefoon. Probeer dit:

1. Zorg ervoor dat het opgeroepen telefoonnummer juist is. Gebruik een handset om het ontvangende nummer te bellen.

2. Zorg ervoor dat een handvraag de antwoordasynchrone modem kan bereiken. Als een handvraag de antwoordende asynchrone modem kan bereiken, kan de lijn BRI niet voorzien worden om uitgaande spraakoproepen toe te staan.

3. Als een handmatige oproep niet in staat is om de antwoordasynchrone modem te bereiken, verander de telefoonkabels op de ontvangende modem en probeer een regelmatige telefoon op de lijn van de ontvangende modem. Als de oproep via de gewone telefoon kan worden ontvangen, is er waarschijnlijk een probleem met de ontvangende modem.

4. Als het handmatige gesprek nog steeds niet in staat is om de gewone telefoon op de betreffende lijn te bereiken, probeer dan een andere (bekende goede) lijn in de ontvangende faciliteit. Als dat verbinding maakt, moet u de telco-lijn laten controleren die naar de ontvangende modem gaat.

5. Als dit een langeafstandsbediening is, probeert u de oorspronkelijke kant een ander (bekend goed) langeafstandsnummer. Als dat werkt, kan de ontvangende faciliteit of de ontvangende lijn niet voorzien worden om lange-afstandsgesprekken te ontvangen. Als de lijn van oorsprong (BRI) geen andere lange afstand getallen kan bereiken, kan deze geen lange afstand hebben geactiveerd. Probeer 10-10 codes voor verschillende langeafstandsbedrijven.

6. Probeer tenslotte een ander (bekend goed) lokaal nummer van de oorsprong BRI lijn. Als de verbinding nog steeds faalt, dient u telco de BRI te controleren.

- Mogelijkheid 3: Het nummer dat wordt gedraaid is niet correct. Controleer het nummer door het handmatig in te stellen. Corrigeer de configuratie indien nodig.

- Mogelijkheid 4: De modemtraining duurt te lang of de TIMEOUT-waarde is te laag. Probeer de TIMEOUT-waarde in de chat-script opdracht te verhogen. Als de TIMEOUT al 60 seconden of langer is, kan er een kabelprobleem zijn tussen de modem en de DTE waaraan het is gekoppeld. Trainingsfouten kunnen ook duiden op een stroomprobleem of modemoncompatibiliteit.

Om bij de onderkant van een individueel modemprobleem te komen, gaat u naar de AT-prompt bij de oorspronkelijke modem met reverse telnet. Gebruik indien mogelijk ook reverse telnet om de AT-prompt van de ontvangende modem te bereiken. Gebruik ATM1 om de modem te laten om geluiden naar zijn luidspreker te sturen zodat de mensen aan elk eind kunnen horen wat op de lijn gebeurt.

Heeft de muziek geluid? Als dit het geval is, reinigt u het circuit. Als de asynchrone modems niet omhoog trainen, roep het nummer en luister naar statisch. Er kunnen andere factoren zijn die de trein bemoeilijken. Achteruit telnet naar de asynchrone modem en debug.

5. Als alles goed werkt en u nog steeds geen verbinding kunt maken op uw BRI asynchrone modem DDR, probeer dan PPP het zuiveren. Als het chat-script succesvol is voltooid en de PPP-debugs duiden op een storing, raadpleeg dan de sectie "Problemen oplossen PPP" in hoofdstuk 17 van de Guide voor probleemoplossing tussen netwerken.

PRI ISDN DDR

1. Na het eerste vermoeden van een ISDN-storing op een PRI, controleert u altijd de uitvoer van de ISDN-status. De belangrijkste dingen om op te merken zijn dat Layer 1 actief zou moeten zijn en Layer 2 zou in een staat van MULTIPLE_FRAME_ESTABLISHED moeten zijn. Zie Hoofdstuk 16 van de gids voor probleemoplossing voor Internetwork, "Interpreting Show ISDN Status" voor informatie over het lezen van deze uitvoer en corrigerende maatregelen.

Voor uitgaande vraag van ISDN, debug isdn q931 en debug isdn zijn de beste gereedschappen om te gebruiken. Gelukkig, het zuiveren van uitgaande oproepen is zeer gelijkaardig aan het zuiveren van inkomende oproepen. Een normale succesvolle oproep ziet er zo uit:

*Mar 20 21:07:45.025: ISDN SE0:23: Event:

Call to 5553759 at 64 Kb/s

*Mar 20 21:07:45.033: ISDN SE0:23: TX ->  SETUP pd = 8

callref = 0x2C

*Mar 20 21:07:45.037:         Bearer Capability i = 0x8890

*Mar 20 21:07:45.041:         Channel ID i = 0x83

*Mar 20 21:07:45.041:         Keypad Facility i = 0x35353533373539

*Mar 20 21:07:45.141: ISDN SE0:23: RX <-  CALL_PROC pd = 8

callref = 0xAC

*Mar 20 21:07:45.145:         Channel ID i = 0x89

*Mar 20 21:07:45.157: ISDN SE0:23: received HOST_PROCEEDING

Channel ID i = 0x0101

*Mar 20 21:07:45.161:   -------------------

Channel ID i = 0x89

*Mar 20 21:07:45.313: ISDN SE0:23: RX <-  CONNECT pd = 8

callref = 0xAC

*Mar 20 21:07:45.325: ISDN SE0:23: received HOST_CONNECT

Merk op dat het CONNECT-bericht de belangrijkste indicator voor het succes is. Als er geen CONNECT is ontvangen, ziet u een DISCONNECT of een RELEASE_COMP (release complete) bericht gevolgd door een oorzaakcode:

*Mar 20 22:11:03.212: ISDN SE0:23: RX <-  RELEASE_COMP pd = 8

callref = 0x8F

*Mar 20 22:11:03.216:         Cause i = 0x8295 - Call rejected

De waarde van de oorzaak duidt op twee dingen.

- De tweede byte van de 4- of 6-byte-waarde geeft het punt aan in het end-to-end call pad waaruit de DISCONNECT of RELEASE_COMP is ontvangen. Dit kan u helpen om het probleem te lokaliseren.

- De derde en vierde bytes geven de werkelijke reden voor de fout aan. Zie Tabel 9 voor de betekenis van de verschillende waarden.

Opmerking: de volgende afdruk duidt op een storing in een hoger protocol:

Cause i = 0x8090 - Normal call clearing

Een typische reden voor PPP-authenticatie. Schakel de optie debug ppp onderhandeling in en debug ppp verificatie voordat u ervan uitgaat dat de verbindingsfout noodzakelijkerwijs een ISDN-probleem is.

2. Als het ISDN CONNECT-bericht wordt weergegeven en de PPP-instellingen duiden op een storing, raadpleeg de sectie "Problemen oplossen PPP" in hoofdstuk 17 van de Guide voor probleemoplossing tussen netwerken.

BRI ISDN DDR

1. Na het eerste vermoeden van een mislukking van ISDN op een BRI, controleer altijd de uitvoer van de ISDN-status. De belangrijkste dingen om op te merken zijn dat Layer 1 actief zou moeten zijn en Layer 2 zou in een staat van MULTIPLE_FRAME_ESTABLISHED moeten zijn. Zie het Hoofdstuk 16 van de Handleiding voor probleemoplossing tussen netwerken, "Tolken tonen ISDN-status" voor informatie over het lezen van deze uitvoer en corrigerende maatregelen.

Voor uitgaande vraag van ISDN, debug isdn q931 en debug isdn zijn de beste gereedschappen om te gebruiken. Gelukkig, het zuiveren van uitgaande oproepen is zeer gelijkaardig aan het zuiveren van inkomende oproepen. Een normale succesvolle oproep ziet er zo uit:

*Mar 20 21:07:45.025: ISDN BR0: Event: Call to 5553759 at 64 Kb/s

*Mar 20 21:07:45.033: ISDN BR0: TX ->  SETUP pd = 8  callref = 0x2C

*Mar 20 21:07:45.037:         Bearer Capability i = 0x8890

*Mar 20 21:07:45.041:         Channel ID i = 0x83

*Mar 20 21:07:45.041:         Keypad Facility i = 0x35353533373539

*Mar 20 21:07:45.141: ISDN BR0: RX <-  CALL_PROC pd = 8  callref = 0xAC

*Mar 20 21:07:45.145:         Channel ID i = 0x89

*Mar 20 21:07:45.157: ISDN BR0: received HOST_PROCEEDING

Channel ID i = 0x0101

*Mar 20 21:07:45.161:   -------------------

Channel ID i = 0x89

*Mar 20 21:07:45.313: ISDN BR0: RX <-  CONNECT pd = 8  callref = 0xAC

*Mar 20 21:07:45.325: ISDN BR0: received HOST_CONNECT

Merk op dat het CONNECT-bericht de belangrijkste indicator voor het succes is. Als er geen CONNECT is ontvangen, ziet u een DISCONNECT of een RELEASE_COMP (release complete) bericht gevolgd door een oorzaakcode:

*Mar 20 22:11:03.212: ISDN BR0: RX <-  RELEASE_COMP pd = 8

callref = 0x8F

*Mar 20 22:11:03.216:         Cause i = 0x8295 - Call rejected

De waarde van de oorzaak duidt op twee dingen.

- De tweede byte van de 4- of 6-byte-waarde geeft het punt aan in het end-to-end call pad waaruit de DISCONNECT of RELEASE_COMP is ontvangen. Dit kan u helpen om het probleem te lokaliseren.

- De derde en vierde bytes geven de werkelijke reden voor de fout aan. Zie Tabel 9 voor de betekenis van de verschillende waarden.

Opmerking: de volgende afdruk duidt op een storing in een hoger protocol:

Cause i = 0x8090 - Normal call clearing

Een typische reden voor PPP-authenticatie. Schakel de optie debug ppp onderhandeling in en debug ppp verificatie voordat u ervan uitgaat dat de verbindingsfout noodzakelijkerwijs een ISDN-probleem is.

2. Als het ISDN CONNECT-bericht wordt weergegeven en de PPP-instellingen duiden op een storing, raadpleeg de sectie "Problemen oplossen PPP" in hoofdstuk 17 van de Guide voor probleemoplossing tussen netwerken.

Gerelateerde informatie

- Cisco IOS-handleiding voor snelle configuratie van kiesservices

- Cisco IOS-configuratiegids voor kiesservices: Netwerkservices

- Cisco IOS-configuratiegids voor kiesservices: Terminalservices

- Cisco IOS-opdracht voor kiesservices

- Overzicht van casestudy’s

- Access Technology-pagina's

- Technische ondersteuning en documentatie – Cisco Systems