Connectiviteit met kiesfunctiekaart voor probleemoplossing - IOS DDR

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).

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.

Dialer1: Can't place call, no dialer pool set

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