Kiezertechnologie: Technieken voor probleemoplossing
Inhoud
Inleiding
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 telefoonschakelaar een telefoonnummer stuurt om een verbinding te sturen. Cisco3600, AS5200, AS5300, en AS5800 zijn alle voorbeelden van routers die de mogelijkheid hebben om een PRI samen met banken van digitale modems te starten. Aan de andere kant is de AS2511 een voorbeeld van een router die met externe modems communiceert.
Voorwaarden
Vereisten
Lezers van dit document moeten op de hoogte zijn van:
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 BRI in het PSTN worden aangesloten gegevens via meer dan 53k kunnen verzenden met behulp van de V.90 communicatiestandaard bewijst het succes van het idee.
De eerste toegangsservers waren Cisco2509 en Cisco2511. De AS2509 kon 8 inkomende verbindingen ondersteunen met externe modems en de AS2511 kon 16 ondersteunen. De AS5200 werd geïntroduceerd met 2 PRIs en kon 48 gebruikers ondersteunen met digitale modems, en het vertegenwoordigde een belangrijke 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.
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.
Conventies
Raadpleeg Cisco Technical Tips Conventions (Conventies voor technische tips van Cisco) voor meer informatie over documentconventies.
Problemen oplossen bij inkomende oproepen
Problemen oplossen en binnenkomende telefoontjes beginnen onderaan en werken omhoog. De algemene redeneringsstroom bestaat uit de volgende:
-
Zien we het telefoontje aankomen? (Een ja-antwoord gaat in op de volgende vraag)
-
Beantwoordt het ontvangende eind de oproep?
-
Is de oproep klaar?
-
Worden data over de link heen?
-
Is de zitting ingesteld? (PPP of terminal)
Voor modemverbindingen ziet een gegevensvraag er hetzelfde uit als een eindsessie die tot het eind komt waar de gegevensvraag om PPP gaat onderhandelen.
Voor inkomende oproepen die digitale modems omvatten, zorg eerst dat de onderliggende ISDN of CAS de vraag ontvangt. Als u een externe modem gebruikt, kunnen de ISDN- en CAS-groepssecties worden overgeslagen.
Problemen oplossen bij ISDN-oproepen
Gebruik de opdracht debug isdn q931. Hier is een voorbeelduitvoer van een succesvolle verbinding:
Router# debug isdn q931 RX <- SETUP pd = 8 callref = 0x06 Bearer Capability i = 0x8890 Channel ID i = 0x89 Calling Party Number i = 0x0083, `5551234' TX -> CONNECT pd = 8 callref = 0x86 RX <- CONNECT_ACK pd = 8 callref = 0x06
Het setup-bericht geeft aan dat een verbinding wordt gestart door het externe gedeelte. De aanroep referentienummers worden als twee behouden. In dit geval is het nummer van de aanroep voor de inkomende kant van de verbinding 0x06, en het nummer van de aanroep van de uitgaande kant van de verbinding is 0x86. De mogelijkheden van de drager (vaak aangeduid als de achtergrond) vertellen de router wat voor soort aanroep er binnenkomt. In dit geval is de verbinding type 0x890. Die waarde duidt op "ISDN Speed 64 Kb/s". Als het bearercap 0x8090A2 was geweest, zou het hebben aangegeven "Speech/Voice call u-law".
Als er geen setup-bericht is binnengekomen, dient u het juiste nummer te controleren door het handmatig te bellen, als het om een spraakvoorziening gaat. U dient de status van de ISDN-interface ook te controleren (raadpleeg de opdracht ISDN-status voor BRI-probleemoplossing gebruiken). Als dat allemaal uitcheckt, zorg er dan voor dat de bedenker van de oproep de juiste aanroep maakt. Dit kan gedaan worden door contact op te nemen met het telefoonbedrijf. De bedenker van de vraag kan de vraag vinden om te zien waar het wordt verzonden. Als de verbinding een lange afstand is, probeer dan een andere langeafstandsbediening met behulp van een 1010 langeafstandscode.
Als de oproep die binnenkomt een asynchrone modemvraag is, zorg ervoor dat de lijn van tevoren is voorzien om spraakoproepen toe te staan.
Opmerking: BRI asynchrone modem is een functie van 3600 routers die 12.0(3)T of hoger draaien. Het vereist een recente hardwareherziening van de BRI interface netwerk module. WIC modules ondersteunen geen asynchrone modemaanroep.
Als de oproep aankwam maar niet voltooid was, zoek dan een broncode (zie Tabel 17-10). Een geslaagde voltooiing wordt aangegeven door connect-ack.
Als dit een asynchrone modemoproep is, gaat u vooruit naar het gedeelte "Problemen oplossen bij inkomende modem".
Op dit punt wordt de ISDN-oproep aangesloten, maar er zijn geen gegevens gezien die over de link komen. Gebruik de opdracht debug ppp onderhandelen om te zien of er verkeer in PPP over de lijn komt. Als u geen verkeer ziet, kan er een snelheidsfout optreden. Om te bepalen als dit het geval is, gebruik het tonen in werking stellen-in werking stellen-enig bevoorrechte bevel om de routerconfiguratie te bekijken. Controleer de opdrachten voor de configuratie van de dialer-interface in de lokale router en de router op afstand. Deze items moeten op de volgende punten lijken:
dialer map ip 131.108.2.5 speed 56 name C4000
Voor dialerprofielen moet een map-klasse worden gedefinieerd om de snelheid in te stellen. Merk op dat de standaardinstelling is dat ISDN-interfaces proberen 64K-communicatiesnelheden te gebruiken op elk kanaal.
Raadpleeg voor gedetailleerde informatie over het configureren van dialerkaarten en profielen de Cisco IOS-configuratiegids voor kiesoplossingen, de opdracht Kiesoplossingen en de Snelle configuratiegids voor kiesoplossingen.
Als u geldige PPP-pakketten ontvangt, wordt de link ingeschakeld en werkt u. U dient nu te gaan naar het gedeelte "Problemen oplossen PPP".
Inkomende CAS-gespreksprobleemoplossing
Als u een oplossing wilt vinden voor de CAS-groep die connectiviteit op de modems aanbiedt, gebruikt u de opdrachten debug-modem, debug-csm en debug-cas voor modems.
Opmerking: de debug cas-opdracht is voor het eerst verschenen in 12.0(7)T voor de AS5200 en AS5300. Eerdere versies van IOS gebruiken de interne configuratie van het systeemniveau samen met de exec-opdracht modemgarantie debug rbs. Het afluisteren van deze informatie op een AS5800 vereist verbinding met de kofferkaart zelf.
Bepaal eerst of de schakelaar van het telefoonbedrijf "van de haak"ging om de inkomende vraag te signaleren. Zo niet, controleer het nummer dat wordt opgeroepen. Doe dit door een telefoon aan de telefoonlijn van de vertrekkende partij te bevestigen en het nummer te bellen. Als de oproep goed wordt ingestuurd, ligt het probleem in de oorspronkelijke CPE. Als de oproep nog steeds niet op de CAS verschijnt, controleer dan de T1 (hoofdstuk 15).In dit geval, gebruik de opdracht debug seriële interfaces.
Dit toont een goede verbinding met debug-modem met CSM:
Router# debug modem csm CSM_MODEM_ALLOCATE: slot 1 and port 0 is allocated. MODEM_REPORT(0001): DEV_INCALL at slot 1 and port 0 CSM_PROC_IDLE: CSM_EVENT_ISDN_CALL at slot 1, port 0 CSM_RING_INDICATION_PROC: RI is on CSM_RING_INDICATION_PROC: RI is off CSM_PROC_IC1_RING: CSM_EVENT_MODEM_OFFHOOK at slot 1, port 0 MODEM_REPORT(0001): DEV_CONNECTED at slot 1 and port 0 CSM_PROC_IC2_WAIT_FOR_CARRIER: CSM_EVENT_ISDN_CONNECTED at slot 1, port 0
In dit voorbeeld werd de oproep gericht aan een modem. Als uw oproep tot een modem is gericht, gaat u naar het onderstaande gedeelte "Problemen oplossen bij inkomende modem".
Problemen oplossen bij inkomende modem
Gebruik de volgende debug-opdrachten wanneer u inkomende modemoproepen wilt oplossen:
-
modem reinigen
-
debug-modem (voor geïntegreerde digitale modems)
Gebruik de volgende debug opdrachten in combinatie om aan te geven dat de nieuwe oproep binnenkomt:
-
debug van ISDN Q931
-
afkappen
aangenomen dat de oproep de modem bereikt, moet de modem de oproep oppikken.
Tips voor het fouilleren van externe modems
Om het debuggen op een externe modem te vergemakkelijken die op een TTY lijn wordt aangesloten, verhoog het sprekersvolume. Dit helpt een aantal problemen duidelijker te maken.
Wanneer de oorspronkelijke modem belt, heeft de ontvangende modemring? Is dit niet het geval, controleer het nummer en probeer een handmatige oproep vanaf de afstandsbediening. Probeer ook een gewone telefoon op het ontvangende eind te gebruiken. Vervang kabels en hardware indien nodig.
Pickup voor asynchrone modem
Als een externe modem niet antwoordt, controleer de bekabeling tussen de modem en de toegangsserver of router. Bevestig dat de modem met de TTY of de hulphaven op de router met een gewalste RJ-45 kabel en een MMOD DB-25 adapter is verbonden. Cisco raadt deze kabelconfiguratie aan en ondersteunt deze voor RJ-45-poorten. Merk op dat deze connectors doorgaans zijn geëtiketteerd: Modem.
RJ45-bekabeling wordt geleverd in een paar typen: recht, gewalst en oversteekplaats. U kunt het bekabeltype bepalen door de twee uiteinden van een RJ-45 kabel naast elkaar te houden. Je ziet acht gekleurde strips of spelden aan elk uiteinde.
-
Als de volgorde van de gekleurde spelden aan elk uiteinde gelijk is, is de kabel recht.
-
Als de volgorde van de kleuren aan elk eind wordt omgekeerd, wordt de kabel gerold.
-
De kabel is een kruiskabel als de kleuren het volgende aangeven:
RJ45 naar RJ45-kruiskabel:
RJ45 RJ45
5 ------------------ 2
2 ------------------ 5
4 ------------------ 1
1 ------------------ 4
Om ervoor te zorgen dat de signalering OK is, gebruikt u de opdracht Show line (stippellijn) in hoofdstuk 16.
Afgezien van bekabeling moet een externe modem worden geformatteerd voor een automatisch antwoord. Controleer de afstandsmodem om te zien of deze is ingesteld op een automatisch antwoord. Meestal is er een AA-indicatielampje ingeschakeld wanneer het auto-antwoord is ingesteld. Stel de afstandsmodem in op automatisch antwoord als deze nog niet is ingesteld. Raadpleeg uw modemdocumentatie voor informatie over het controleren en wijzigen van de instellingen van de modem. Gebruik een omgekeerde telnet om de modem te initialiseren (raadpleeg hoofdstuk 16).
Call Pickup voor digitale (geïntegreerde) modem
Op een externe modem is het duidelijk of de vraag wordt beantwoord, maar de interne modems vereisen een handmatige vraag aan het ontvangende nummer. Luister naar de reactie-achtertoon. Als u geen ABT hoort, controleert u de configuratie op de volgende twee punten:
-
Zorg ervoor dat de opdracht ISDN-inkomende spraakmodem bestaat onder elke ISDN-interface die inkomende modemverbindingen verwerkt.
-
Zorg er onder de lijnconfiguratie voor de TTY van de modem voor dat de modeminformatie bestaat.
Het is ook mogelijk dat de Call Switching Module (CSM) geen interne modem toegewezen heeft gekregen om de inkomende vraag aan te pakken. Dit probleem kan worden veroorzaakt door modem- of hulppools die voor te weinig inkomende verbindingen worden gevormd. Dit kan ook betekenen dat de toegangsserver mogelijk niet over modems beschikt. Controleer de beschikbaarheid van modems en pas de instellingen van de modempool of van de resource pool op de juiste manier aan. Als een modem werd toegewezen en de configuratie modeminformatie toont, verzamel ideeën en neem contact met Cisco voor hulp.
Modemtraining
Als de ontvangende modem DSR opheft, was de training succesvol. Trainingsfouten kunnen duiden op een stroomprobleem of modemoncompatibiliteit.
Ga naar de AT-prompt bij de oorspronkelijke modem om het probleem bij de onderkant van een individueel modemprobleem op te lossen. Als u een digitale modem in een Cisco-toegangsserver aanroept, moet u bereid zijn om een .wav-bestand van de trainingsmuziek, of DIL (Digital Subscriber Line), op te nemen. DIL is de musical score (PCM sequentie) die de oorspronkelijke V.90-analoge modem tegen het ontvangende digitale modem vertelt om terug te spelen. Met de sequentie kan de analoge modem elke digitale beschadiging in het circuit onderkennen; zoals meerdere D/A-conversies, een wet/u-wet, beroofde bits of digitale kussens. Als u de DIL niet hoort, hebben de modems niet V.90 in V.8/V.8bis (dat wil zeggen, een probleem met modemcompatibiliteit) onderhandeld. Als u de DIL hebt gehoord en u een hertrein hebt genomen in V.34, heeft de analoge modem (op basis van de DIL afspelen) besloten dat V.90 niet uitvoerbaar was.
Heeft de muziek geluid? Als dit het geval is, reinigt u het circuit.
Geeft de klant snel op zonder V.34-training? Bijvoorbeeld, misschien weet het niet wat te doen als het V.8bis hoort. In dit geval dient u te proberen V.8bis (dus K56Flex) op de server uit te schakelen (indien acceptabel). U zou nieuwe client firmware moeten krijgen of de client modems moeten vervangen. Alternatief kon het dialing-einde vijf komma's aan het eind van de wijzerplaat invoegen. Dit vertraagt de luister van de oproepende modem en zal de toon van V.8bis van de ontvangende server tot tijd veroorzaken zonder de clientmodem te beïnvloeden. Vijf komma's in de wijzerplaat zijn een algemeen richtsnoer en moeten wellicht aangepast worden om rekening te houden met lokale omstandigheden.
Sessiebedrijf
Op dit punt in de volgorde worden de modems aangesloten en opgeleid. Nu is het tijd om te weten te komen of er verkeer is dat goed overkomt.
Als de lijn die de vraag ontvangt met autoselectieve PPP wordt gevormd en de asynchrone interface met asynchrone modus interactief wordt gevormd, gebruik de opdracht debug modem om het autoselectieproces te verifiëren. Als het verkeer via de asynchrone link binnenkomt, zal de toegangsserver het verkeer onderzoeken om te bepalen of het verkeer op karakter of op pakket gebaseerd is. Afhankelijk van de bepaling, zal de toegangsserver dan een PPP sessie starten of niet verder gaan dan een sessie op de lijn.
Een normale autoselect reeks met inkomende PPP LCP-pakketten:
*Mar 1 21:34:56.958: TTY1: DSR came up *Mar 1 21:34:56.962: tty1: Modem: IDLE->READY *Mar 1 21:34:56.970: TTY1: EXEC creation *Mar 1 21:34:56.978: TTY1: set timer type 10, 30 seconds *Mar 1 21:34:59.722: TTY1: Autoselect(2) sample 7E !--- The inbound traffic is displayed in hexadecimal format. This is based on the !--- bits coming in over the line, regardless of whether the bits are ASCII !--- characters or elements of a packet. The bits represented in this example are !--- correct for a LCP packet. Anything different would be either a malformed packet !--- or character traffic. *Mar 1 21:34:59.726: TTY1: Autoselect(2) sample 7EFF *Mar 1 21:34:59.730: TTY1: Autoselect(2) sample 7EFF7D *Mar 1 21:34:59.730: TTY1: Autoselect(2) sample 7EFF7D23 *Mar 1 21:34:59.734: TTY1 Autoselect cmd: ppp negotiate !--- Having determined that the inbound traffic is actually an LCP packet, the access !--- server triggers the PPP negotiation process. *Mar 1 21:34:59.746: TTY1: EXEC creation *Mar 1 21:34:59.746: TTY1: create timer type 1, 600 seconds *Mar 1 21:34:59.794: TTY1: destroy timer type 1 (OK) *Mar 1 21:34:59.794: TTY1: destroy timer type 0 *Mar 1 21:35:01.798: %LINK-3-UPDOWN: Interface Async1, changed state to up !--- The async interface changes state to up, and the PPP negotiation (not shown) !--- commences.
Als de oproep een PPP zitting is en als de asynchrone modus toegewijd is op de asynchrone interface wordt ingesteld, debug de PPP onderhandeling van de opdracht om te zien of om het even welke pakketten van het configuratieverzoek van het verre eind komen. De debugs tonen deze als CONFREQ. Als u zowel inkomende als uitgaande PPP pakketten observeert, gaat u naar "Problemen oplossen PPP". Anders sluit u een verbinding aan van het Call-Connector met een teken-mode (of "exec") sessie (dat wil zeggen een niet-PPP-sessie).
Opmerking: Als het ontvangende end asynchrone modem toont die onder de asynchrone interface gewijd is, toont een exec dial-peer slechts wat op ascII afval lijkt te zijn. Om een eindsessie toe te staan en nog steeds PPP vermogen te hebben, gebruik de asynchrone wijze van de interfaceconfiguratie interactief. Gebruik onder de configuratie van de gekoppelde regel de optie automatisch selecteren.
Modem kan geen gegevens verzenden of ontvangen
Als de modems verbinding maken met een eindsessie en er geen gegevens binnenkomen, controleer dan de volgende mogelijke oorzaken en voorgestelde acties:
-
Instelling modemsnelheid is niet vergrendeld
-
Gebruik het bevel van de showline exec op de toegangsserver of router. De uitvoer voor de hulppoort moet de momenteel ingestelde Tx- en Rx-snelheden aangeven.
Voor een verklaring van de output van het bevel van de tonen lijn, zie het "Gebruik Debug Commands"gedeelte in hoofdstuk 15.
-
Als de lijn niet op de juiste snelheid is ingesteld, gebruikt u de opdracht voor het configureren van de snellijn om de lijnsnelheid op de toegangsserver of routerlijn in te stellen. Stel de waarde in op de hoogste snelheid gemeenschappelijk tussen de modem en de toegangsserver of routerpoort. Om de terminale basissnelheid in te stellen gebruikt u de configuratieopdracht voor de snelheidslijn. Deze opdracht stelt zowel het transport (naar terminal) in als het ontvangen (van terminal) snelheden.
Syntaxis:
snelheid Gbps
Synthetisch Beschrijving:
bps - standaardtarief in bits per seconde (bps). De standaard is 9600 bps.
Het volgende voorbeeld stelt lijnen 1 en 2 op een Cisco 2509 toegangsserver in op 115200 bps:
line 1 2 speed 115200
Opmerking: Als u om de een of andere reden geen flow control kunt gebruiken, beperkt u de lijnsnelheid tot 9600 bps. Snellere snelheden leiden waarschijnlijk tot verloren gegevens.
-
Gebruik nogmaals de opdracht Show line exec en bevestig dat de lijnsnelheid is ingesteld op de gewenste waarde.
-
Wanneer u zeker bent dat de toegangsserver of routerlijn voor de gewenste snelheid is geconfigureerd, initieert u een omgekeerde telnet-sessie naar de modem via die lijn. Zie voor meer informatie het gedeelte "Het instellen van een omgekeerde telelensessie op een modem" in hoofdstuk 16.
-
Gebruik een modemopdrachtstring die de opdracht "lock DTE speed" voor uw modem bevat. Zie uw modemdocumentatie voor de exacte syntaxis van uw configuratie.
Opmerking: de opdracht Slot DTE-snelheid, die ook kan worden aangeduid als poortsnelheid aanpassen of gebufferde modus, is vaak gerelateerd aan de manier waarop de modem foutcorrectie verwerkt. Deze opdracht varieert sterk van de ene modem tot de andere.
Door de modemsnelheid te vergrendelen wordt gewaarborgd dat de modem altijd met de Cisco-toegangsserver of -router communiceert met de snelheid die op de Cisco hulppoort is ingesteld. Als deze opdracht niet wordt gebruikt, keert de modem terug naar de snelheid van de datalink (de telefoonlijn), in plaats van te communiceren met de snelheid die op de toegangsserver wordt ingesteld.
-
-
Hardware stroomcontrole niet ingesteld op een lokale of externe modem of router
-
Gebruik de opdracht aux-line-number exec en kijk in het veld Capability naar het volgende:
Capabilities: Hardware Flowcontrol In, Hardware Flowcontrol Out
Raadpleeg voor meer informatie de uitgangen van de in hoofdstuk 16 voorkomende interpreteer-lijn.
Als in dit veld geen melding wordt gemaakt van de regeling van de hardwarestroom, is de controle van de hardwarekoming niet op de lijn ingeschakeld. Aanbevolen wordt de hardware-flow control voor access server-to-modemverbindingen te gebruiken.
Voor een verklaring van de output van het bevel van de tonen lijn, zie de sectie "Gebruik Debug Commands" in hoofdstuk 15.
-
Configuratie van de controle van de hardwarestroom op de lijn met de de configuratieopdracht van de stroomregellijn.
Om de methode van de controle van de gegevensstroom tussen het terminal of andere seriemiddel en de router in te stellen, gebruik de opdracht voor het configureren van de lijn van de stroomregellijn. Gebruik het nr-formulier van deze opdracht om stroomregeling uit te schakelen.
Syntaxis:
debiet {geen | software [vergrendeld] [in] | uit] | hardware [in] | uit]
Synthetisch Beschrijving:
-
geen - schakelt de stroomregeling uit.
-
software - Hiermee stelt u de softwareflow-control in. Een optioneel trefwoord geeft de richting aan: veroorzaakt dat de Cisco IOS-software luistert naar stroomcontrole van het aangesloten apparaat en veroorzaakt dat de software stroomregelinformatie naar het aangesloten apparaat stuurt. Als u geen richting specificeert, worden beide aangenomen.
-
vergrendeling - Daardoor kan de stroomregeling niet van de afstandsbediening worden uitgeschakeld als de aangesloten apparatuur de softwareflow-regeling nodig heeft. Deze optie is van toepassing op verbindingen met de Telnet- of rlogin protocollen.
-
hardware - Hiermee stelt u de regeling van de hardwarestromen in. Een optioneel trefwoord geeft de richting aan: laat de software luisteren naar de stroomregeling van het aangesloten apparaat en zorgt ervoor dat de software stroomregelinformatie naar het aangesloten apparaat stuurt . Als u geen richting specificeert, worden beide aangenomen. Voor meer informatie over de controle van de hardwarestroom, zie de hardwarehandleiding die met uw router werd verscheept.
Voorbeeld:
Het volgende voorbeeld stelt de controle van de hardwaredebiet op lijn 7 in:
line 7 flowcontrol hardware
Opmerking: als u om de een of andere reden geen flow control kunt gebruiken, beperkt u de lijnsnelheid tot 9600 bps. Snellere snelheden leiden waarschijnlijk tot verloren gegevens.
-
-
Nadat u de controle van de hardwareflow op de toegangsserver of routerlijn hebt ingeschakeld, stelt u een omgekeerde telnet-sessie voor de modem in via die lijn. Zie voor meer informatie het gedeelte "Het instellen van een omgekeerde telelensessie op een modem" in hoofdstuk 16.
-
Gebruik een modemopdrachtstring die de RTS/CTS Flow opdracht voor uw modem bevat. Deze opdracht garandeert dat de modem gebruik maakt van dezelfde methode om de stroom te controleren (dat wil zeggen, de controle van de hardwarestroom) als de Cisco toegangsserver of router. Zie uw modemdocumentatie voor de exacte syntaxis van uw configuratie.
-
-
Opdrachten voor dialer onjuist ingesteld
-
Gebruik het tonen in werking stellen-in werking stellen-enig bevel om de routerconfiguratie te bekijken. Controleer de opdrachtitems van dialer om te zien of het uitgezonden sleutelwoord is gespecificeerd.
-
Als het sleutelwoord ontbreekt, voeg het aan de configuratie toe.
Syntaxis:
dialer map protocol next-hop-adres [naam hostname] [uitzending] [dial-string]
Synthetisch Beschrijving:
-
protocol - Het protocol is onderhevig aan mapping. Mogelijke opties zijn IP, IPX, bridge en snapshot.
-
next-hop-address - Het protocoladres van de asynchrone interface van de tegenovergestelde site.
-
naam hostname - Een vereiste parameter die in PPP authenticatie wordt gebruikt. Het is de naam van de afgelegen site waarvoor de dialerkaart is gemaakt. De naam is hoofdlettergevoelig en moet de hostname van de afstandsrouter overeenkomen.
-
uitzending - Een facultatief sleutelwoord dat pakketten uitzendt (bijvoorbeeld, IP RIP of IPX RIP/SAP updates) die aan de verre bestemming wordt doorgestuurd. In statische het routeren van steekproefconfiguraties, wordt het routingupdates niet gewenst en het uitzending sleutelwoord wordt weggelaten.
-
dial-peers - het telefoonnummer van de verre plaats. Alle toegangscodes (bijvoorbeeld 9 om een kantoor te verlaten, internationale kiescodes, gebiedscodes) moeten worden opgenomen.
-
-
Zorg ervoor dat de opdrachten van de dialerkaart de juiste volgende hopadressen specificeren.
-
Als het volgende hopadres niet correct is, verander het met de opdracht dialerkaart.
-
Zorg ervoor dat alle andere opties in de opdrachten van de dialerkaart correct zijn opgegeven voor het protocol dat u gebruikt.
Raadpleeg voor meer informatie over het configureren van dialerkaarten de Cisco IOS Wide Area Network Configuration Guide en de Wide Area Network Commision.
-
-
Probleem met inbellen
-
Zorg ervoor dat de inbelmodem operationeel is en veilig op de juiste poort is aangesloten. Bepaal of een andere modem werkt wanneer verbonden met dezelfde poort.
-
Het afluisteren van een inkomende exc sessie valt over het algemeen in een paar hoofdcategorieën:
Kiezerclient ontvangt geen snelle verbinding
-
Automatisch selecteren is ingeschakeld op de lijn
Probeer toegang tot de exec-modus te verkrijgen door op ENTER te drukken.
-
De lijn is ingesteld met de geen exec-opdracht
-
Gebruik de opdracht Spraalafstand om de status van de juiste regel te bekijken.
Controleer het veld Capability om te zien of het "EXec suppressed" zegt. Als dit probleem zich voordoet, is de opdracht voor het configureren van de exec-lijn ingeschakeld.
-
Configureer de opdracht voor de configuratie van de exec-lijn op de lijn zodat sessies kunnen worden geïnitieerd. Deze opdracht heeft geen argumenten of trefwoorden.
Het volgende voorbeeld wordt op lijn 7 ingeschakeld:
line 7 exec
-
-
Flow control is niet ingeschakeld.
of
Flow control is slechts op één apparaat (DTE of DCE) ingeschakeld.
of
Flow control is verkeerd ingesteld.
-
Gebruik de opdracht aux-line-number exec en kijk in het veld Capability naar het volgende:
Capabilities: Hardware Flowcontrol In, Hardware Flowcontrol Out
Raadpleeg voor meer informatie de uitgangen van de in hoofdstuk 16 voorkomende interpreteer-lijn.
Als in dit veld geen melding wordt gemaakt van de regeling van de hardwarestroom, is de controle van de hardwarekoming niet op de lijn ingeschakeld. Aanbevolen wordt de hardware-flow control voor access server-to-modemverbindingen te gebruiken.
Voor een verklaring van de uitvoer van het bevel van de showlijn, zie het "Gebruik Debug Commands" gedeelte in hoofdstuk 15.
-
Configuratie van de controle van de hardwarestroom op de lijn met de opdracht van de configuratie van de stroomregelaar. Het volgende voorbeeld stelt de controle van de hardwaredebiet op lijn 7 in:
line 7 flowcontrol hardware
Opmerking: als u om de een of andere reden geen flow control kunt gebruiken, beperkt u de lijnsnelheid tot 9600 bps. Snellere snelheden leiden waarschijnlijk tot verloren gegevens.
-
Nadat u de controle van de hardwareflow op de toegangsserver of routerlijn hebt ingeschakeld, stelt u een omgekeerde telnet-sessie voor de modem in via die lijn. Zie voor meer informatie het gedeelte "Het instellen van een omgekeerde telelensessie op een modem" in hoofdstuk 16.
-
Gebruik een modemopdrachtstring die de RTS/CTS Flow opdracht voor uw modem bevat. Deze opdracht garandeert dat de modem gebruik maakt van dezelfde methode om de stroom te controleren (dat wil zeggen, de controle van de hardwarestroom) als de Cisco toegangsserver of router. Zie uw modemdocumentatie voor de exacte syntaxis van uw configuratie.
-
-
Instelling modemsnelheid is niet vergrendeld
-
Gebruik het bevel van de showline exec op de toegangsserver of router. De uitvoer voor de hulppoort moet de momenteel ingestelde Tx- en Rx-snelheden aangeven.
Voor een verklaring van de uitvoer van het bevel van de showlijn, zie het "Gebruik Debug Commands" gedeelte in hoofdstuk 15.
-
Als de lijn niet op de juiste snelheid is ingesteld, gebruikt u de opdracht voor het configureren van de snelheidslijn om de lijnsnelheid op de toegangsserver of routerlijn in te stellen. Stel de waarde in op de hoogste snelheid gemeenschappelijk tussen de modem en de toegangsserver of routerpoort. Om de eindbasissnelheid in te stellen, gebruikt u de opdracht voor het configureren van de snelheidslijn. Deze opdracht stelt zowel het transport (naar terminal) in als het ontvangen (van terminal) snelheden.
Syntaxis:
snelheid Gbps
Synthetisch Beschrijving:
bps - standaardtarief in bits per seconde (bps). De standaard is 9600 bps.
Voorbeeld:
Het volgende voorbeeld stelt lijnen 1 en 2 op een Cisco 2509 toegangsserver in op 115200 bps:
line 1 2 speed 115200
Opmerking: als u om de een of andere reden geen flow control kunt gebruiken, beperkt u de lijnsnelheid tot 9600 bps. Snellere snelheden leiden waarschijnlijk tot verloren gegevens.
-
Gebruik nogmaals de opdracht Show line exec en bevestig dat de lijnsnelheid is ingesteld op de gewenste waarde.
-
Wanneer u zeker bent dat de toegangsserver of routerlijn voor de gewenste snelheid is geconfigureerd, initieert u een omgekeerde telnet-sessie naar de modem via die lijn. Zie voor meer informatie het gedeelte "Het instellen van een omgekeerde telelensessie op een modem" in hoofdstuk 16.
-
Gebruik een modemopdrachtstring die de snelheidsopdracht van sluis DTE voor uw modem bevat. Zie uw modemdocumentatie voor de exacte syntaxis van uw configuratie.
Opmerking: de opdracht DSL-snelheid, die ook kan worden aangeduid als Poortsnelheid aanpassen of gebufferde modus, is vaak gerelateerd aan de manier waarop de modem foutcorrectie verwerkt. Deze opdracht varieert sterk van de ene modem tot de andere.
Door de modemsnelheid te vergrendelen wordt gewaarborgd dat de modem altijd met de Cisco-toegangsserver of -router communiceert met de snelheid die op de Cisco hulppoort is ingesteld. Als deze opdracht niet wordt gebruikt, keert de modem terug naar de snelheid van de datalink (de telefoonlijn) in plaats van te communiceren met de snelheid die op de toegangsserver wordt ingesteld.
-
Kiezersessies zien "afval"
-
Instelling modemsnelheid is niet vergrendeld
-
Gebruik het bevel van de showline exec op de toegangsserver of router. De uitvoer voor de hulppoort moet de momenteel ingestelde Tx- en Rx-snelheden aangeven.
Voor een verklaring van de output van het bevel van de tonen lijn, zie het "Gebruik Debug Commands"gedeelte in hoofdstuk 15.
-
Als de lijn niet op de juiste snelheid is ingesteld, gebruikt u de opdracht voor het configureren van de snellijn om de lijnsnelheid op de toegangsserver of routerlijn in te stellen. Stel de waarde in op de hoogste snelheid gemeenschappelijk tussen de modem en de toegangsserver of routerpoort.
Om de terminale basissnelheid in te stellen gebruikt u de configuratieopdracht voor de snelheidslijn. Deze opdracht stelt zowel het transport (naar terminal) in als het ontvangen (van terminal) snelheden.
Syntaxis:
snelheid bps
Synthetisch Beschrijving:
bps groeisnelheid in bits per seconde (bps). De standaard is 9600 bps.
Voorbeeld:
Het volgende voorbeeld stelt lijnen 1 en 2 op een Cisco 2509 toegangsserver in op 115200 bps:
regel 1 2
snelheid 11520
Opmerking: als u om de een of andere reden geen flow control kunt gebruiken, beperkt u de lijnsnelheid tot 9600 bps. Snellere snelheden leiden waarschijnlijk tot verloren gegevens.
-
Gebruik nogmaals de opdracht Show line exec en bevestig dat de lijnsnelheid is ingesteld op de gewenste waarde.
-
Wanneer u zeker bent dat de toegangsserver of routerlijn voor de gewenste snelheid is geconfigureerd, initieert u een omgekeerde telnet-sessie naar de modem via die lijn. Zie voor meer informatie het gedeelte "Het instellen van een omgekeerde telelensessie op een modem" in hoofdstuk 16.
-
Gebruik een modemopdrachtstring die de snelheidsopdracht van sluis DTE voor uw modem bevat. Zie uw modemdocumentatie voor de exacte syntaxis van uw configuratie.
Opmerking: de opdracht lock DTE snelheid, die ook kan worden aangeduid als port rate adjustment of buffered mode, is vaak gerelateerd aan de manier waarop de modem foutcorrectie verwerkt. Deze opdracht varieert sterk van de ene modem tot de andere.
Door de modemsnelheid te vergrendelen wordt gewaarborgd dat de modem altijd met de Cisco-toegangsserver of -router communiceert met de snelheid die op de Cisco hulppoort is ingesteld. Als deze opdracht niet wordt gebruikt, keert de modem terug naar de snelheid van de datalink (de telefoonlijn) in plaats van te communiceren met de snelheid die op de toegangsserver wordt ingesteld.
-
Symptoom: De externe dialoogsessie wordt geopend in een reeds bestaande sessie die door een andere gebruiker wordt geïnitieerd. In plaats van een aanmelding te ontvangen, ziet een dialingebruiker een sessie die door een andere gebruiker is ingesteld (wat een UNIX-opdrachtmelding, een teksteditor-sessie enzovoort kan zijn).
Sessiebeheer voor bellen is geopend in bestaande sessie
-
Modem ingesteld voor DCD die altijd hoog is
-
De modem moet opnieuw worden geconfigureerd om alleen op CD-ROM te hebben. Dit wordt meestal bereikt door de modemopdrachtstring &C1 te gebruiken, maar controleer de exacte syntax voor uw modem.
-
Mogelijk moet u de toegangsserverlijn configureren waarop de modem is aangesloten met de opdracht voor het configureren van de exec-lijn. Schakel de lijn uit met de duidelijke lijn bevoorrechte opdracht, open een omgekeerde Telnet-sessie met de modem en pas de modem opnieuw aan zodat DCD alleen op CD hoog is.
-
Maak de Telnet-sessie af door de verbinding in te voeren en pas de toegangsserverlijn aan met de opdracht voor configuratie van de exec-lijn
-
-
De modemcontrole is niet ingeschakeld op de toegangsserver of router
-
Gebruik het bevel van de showline exec op de toegangsserver of router. De output voor de hulppoort moet worden weergegeven in of RIisCD in de modemkolom. Dit geeft aan dat modemcontrole is ingeschakeld op de lijn van de toegangsserver of router.
Voor een verklaring van de uitvoer van de showlijn, zie het "Gebruik Debug Commands" gedeelte in hoofdstuk 15.
-
Configureer de lijn voor modemcontrole met behulp van de configuratieopdracht van de modeminline. De modemcontrole is nu ingeschakeld op de toegangsserver.
N.B.: U kunt de modemopdracht zeker gebruiken in plaats van de opdracht modemdialinering, terwijl de connectiviteit van de modem in kwestie is. Deze laatste opdracht staat de regel toe alleen inkomende oproepen te accepteren. Uitgaande oproepen zullen worden geweigerd, wat het onmogelijk maakt om een Telnet-sessie met de modem aan te leggen om het te configureren. Als u de opdracht modemdialin wilt inschakelen, dient u dit alleen te doen nadat u zeker bent dat de modem correct werkt.
-
-
Onjuiste bekabeling
-
Controleer de bekabeling tussen de modem en de toegangsserver of router. Bevestig dat de modem met de hulppoort op de toegangsserver of router is verbonden met een gerold RJ-45 kabel en een MMOD DB-25 adapter. Deze kabelconfiguratie wordt aanbevolen en ondersteund door Cisco voor RJ-45 poorten. Deze connectors zijn doorgaans voorzien van een label: Modem.
Er zijn twee soorten RJ-45 bekabeling: recht en gerold. Als je de twee uiteinden van een RJ-45 kabel naast elkaar houdt, zie je acht gekleurde strips of spelden aan elk uiteinde. Als de volgorde van de gekleurde spelden aan elk uiteinde gelijk is, dan is de kabel recht. Als de volgorde van de kleuren aan elk eind wordt omgekeerd, dan wordt de kabel gewalst.
De gewalste kabel (CAB-500RJ) is standaard met Cisco's 2500/CS500.
-
Gebruik de opdracht Show line exec om te verifiëren dat de bekabeling correct is. Zie de verklaring van de opdrachtoutput van de show in het gedeelte "Gebruik Debug Commands" in dit hoofdstuk 15.
-
Dialoog-ontvangstmodem wordt niet goed losgekoppeld
-
Modem voelt geen DTR
Geef de Hangup DTR-opdrachtstring op. Deze opdracht vertelt de modem om draagbalk te laten vallen wanneer het DTR-signaal niet langer ontvangen wordt.
Op een Hayes-compatibele modem wordt de &D3 string algemeen gebruikt om Hangup DTR op de modem te configureren. Zie de documentatie voor de exacte syntax van deze opdracht.
-
De modemcontrole is niet ingeschakeld op de router of toegangsserver
-
Gebruik het bevel van de showline exec op de toegangsserver of router. De uitvoer van de hulppoort moet uitwendig zijn of RIisCD in de modemkolom. Dit geeft aan dat modemcontrole is ingeschakeld op de lijn van de toegangsserver of router.
Zie het gedeelte "Debug Commands gebruiken" in hoofdstuk 15 voor een verklaring van de uitvoer van de showlijn.
-
Configureer de lijn voor modemcontrole met behulp van de modemconfiguratie. De modemcontrole is nu ingeschakeld op de toegangsserver.
N.B.: U kunt de modemopdracht zeker gebruiken in plaats van de opdracht modemdialinering, terwijl de connectiviteit van de modem in kwestie is. Deze laatste opdracht staat de regel toe alleen inkomende oproepen te accepteren. Uitgaande oproepen zullen worden geweigerd, wat het onmogelijk maakt om een Telnet-sessie met de modem aan te leggen om het te configureren. Als u de opdracht modemdialin wilt inschakelen, dient u dit alleen te doen nadat u zeker bent dat de modem correct werkt.
-
Uitgebreide oproepen voor probleemoplossing
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 redeneringsstroom bestaat uit de volgende:
-
Initieert het Dial on Demand Routing (DDR) een oproep? (Een ja-antwoord op de volgende vraag)
-
Als dit een asynchrone modem is, geven de chat scripts de verwachte opdrachten uit?
-
Komt de oproep uit bij het PSTN?
-
Beantwoord het afstandseinde de oproep?
-
Is de oproep klaar?
-
Gaat de data over de link?
-
Is de zitting ingesteld? (PPP of Terminal)
Bediening van snelkiezer controleren
Om te zien of probeert de dialer 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 voor een IP-pakket worden uitgevoerd, maakt een lijst van 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).
Verkeer leidt geen kiespoging in
-
Ontbrekende of onjuiste "interessante" verkeersdefinities
-
Gebruik het bevel tonen in werking stellen-beslist, zorg ervoor dat de interface met een dialer-groep wordt gevormd en dat er een mondiaal niveau dialer-list met een overeenkomend aantal is gevormd.
-
Zorg ervoor dat de opdracht dialer-list is ingesteld om een volledig protocol toe te staan of om verkeer toe te staan dat een toegangslijst aanpast
-
Controleer dat de toegangslijst aangeeft dat pakketten die over de link gaan, interessant zijn. Eén nuttige test is om de geprivilegieerde opdracht EXec te gebruiken debug ip-pakket [lijstnummer] met behulp van 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, komt de toegangslijst niet overeen met de pakketten.
-
-
Interfacestatus
Gebruik de opdracht tonen interfaces [interface naam] om ervoor te zorgen dat de interface in de staat "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. Ook moet een back-upvertraging worden ingesteld op de primaire interface, anders wordt de back-upinterface-opdracht nooit uitgevoerd.
Om te controleren of de dialerinterface van "standby" naar "omhoog/omhoog (spoofing)" zal veranderen, is het meestal nodig om de kabel van de primaire interface te halen. Het sluiten van de primaire interface met de shutdown van het configuratiecommando zal de primaire interface niet in "down/down" zetten maar in "administratief omlaag" zetten - niet hetzelfde ding.
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 staat ook bekend als "end-to-end 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 van de dialer interface van de afstandsrouter is. 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 drijvende 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.
Bel niet op zijn plaats
Hieronder worden een aantal mogelijke problemen en voorgestelde acties opgesomd:
-
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 gesteld-klaar om te verzekeren dat de interface van de Kiezer met een dialer pool X opdracht wordt gevormd en dat een dialerinterface op de router met een overeenkomend dialer pool-lid X wordt geconfigureerd. Als de kiesprofielen niet correct zijn geconfigureerd, kunt u een debug-bericht zien zoals:
Dialer1: Can't place call, no dialer pool set
Zorg dat een dialer string is ingesteld.
Async uitgaande bellen - controleer de werking van het chroomscripts
Als de uitgaande vraag een modemvraag is, moet een chatscript worden uitgevoerd om te kunnen 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 toepassingen baseren zich op een chatscript dat in de wereldwijde 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
Problemen met Chatscripts kunnen in drie categorieën worden ingedeeld:
-
Configuratie-fout
-
Modemstoring
-
Verbinding
Chatscripts defect
In deze lijst worden mogelijke uitgangen van debug chat-shows weergegeven en worden acties voorgesteld:
-
geen overeenkomend chatscript gevonden voor [nummer]
Een chatscript is niet ingesteld. Voeg er één toe.
-
Chat script dialout, status = verbinding getimed; externe host niet reageert
De modem reageert niet op het chatscript. Controleer de communicatie met de modem (raadpleeg tabel 16-2 in hoofdstuk 16).
-
Time-outverwachting: VERBINDEN
-
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 kan openen.
-
Mogelijkheid 2: De modem op afstand is geen antwoord. Test dit door de afstandsmodem te bellen met een gewone POTS-telefoon.
-
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. Als de lokale modem extern is, zet het volume van de modemluidspreker omhoog en luister naar de trainingstonen. Als de training abrupt is afgesloten, probeer dan de TIMEOUT waarde in de opdracht chat-script te verhogen. Als de TIMEOUT al 60 seconden of langer is, raadpleegt u het gedeelte Modemtraining.
-
ISDN uitgaande bellen
Na het eerste vermoeden van een ISDN-storing, via een BRI of 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 het gedeelte "ISDN-status omzetten" in hoofdstuk 16 voor informatie over het lezen van deze uitvoer en 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 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
!--- The CONNECT message is the key indicator of success. If a CONNECT is not received, !--- you may see a DISCONNECT or a RELEASE_COMP (release complete) message followed by !--- a cause code (see below)
*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 aan waar in het end-to-end call-pad de DISCONNECT of RELEASE_COMP werd ontvangen. Dit kan u helpen om het probleem te lokaliseren.
-
De derde en vierde bytes geven de werkelijke reden voor de fout aan. Zie de tabellen die volgen voor de betekenis van de verschillende waarden.
Opmerking: de volgende afdruk geeft doorgaans een fout van een hoger protocol aan.
Cause i = 0x8090 - Normal call clearing
Een typische reden voor PPP-authenticatie. Schakel de optie debug PPP-onderhandeling in en debug van PPP-verificatie voordat u ervan uitgaat dat de verbindingsfout noodzakelijkerwijs een ISDN-probleem is
Codetabel
Tabel 17-9 toont de ISDN-oorzaakcodevelden die in de volgende indeling binnen de debug-opdrachten worden weergegeven:
i=0x y1 y2 z1 z2 [a1 a2]
ISDN-oorzaakcodevelden
| Veld | Waarde beschrijving |
|---|---|
| 0x | De volgende waarden zijn in hexadecimaal. |
| Y1 | 8—ITU-T standaardcodering. |
| Y2 | 0—Gebruiker 1—Private netwerk voor lokale gebruiker 2—Publiek netwerk voor lokale gebruiker 3—Doorvoernetwerk 4—Publiek netwerk voor externe gebruiker 5—Private netwerk voor externe gebruiker 7—Internationaal netwerk A—Netwerk voorbij internet |
| z1 | Klasse (het meer significante hexadecimale aantal) van oorzaakwaarde. Raadpleeg de volgende tabel voor gedetailleerde informatie over mogelijke waarden. |
| z2 | Waarde (het minder significante hexadecimale aantal) van oorzaakwaarde. Raadpleeg de volgende tabel voor gedetailleerde informatie over mogelijke waarden. |
| a1 | (Optioneel) Diagnostisch veld dat altijd 8 is. |
| a2 | (Optioneel) Diagnostisch veld dat een van de volgende waarden heeft: 0—onbekend 1—permanent 2—van voorbijgaande aard |
ISDN-oorzaakwaarden
In de volgende tabel worden beschrijvingen gegeven van een aantal van de meest algemeen voorkomende waarden voor de oorzaak van het factor-informatie-element - de derde en vierde bytes van de oorzaakcode. Voor vollediger informatie over ISDN-codes en -waarden, raadpleeg de betekenis van debug van ISDN Q931 Disconnect-oorzaakcodes.
| Hex-waarde | Oorzaak | verklaring |
|---|---|---|
| 81 | Niet-toegewezen (niet-toegewezen) nummer | Het ISDN-nummer is in het juiste formaat naar de schakelaar verzonden. het nummer wordt echter niet aan enige bestemming toegewezen . |
| 90 | Normale gespreksverruiming | Normale callclearing is opgetreden. |
| 91 | Gebruiker druk | Het opgeroepen systeem erkent het aansluitingsverzoek maar kan de oproep niet aanvaarden omdat alle B-kanalen in gebruik zijn. |
| 92 | Geen actie van gebruiker | De verbinding kan niet worden voltooid omdat de bestemming niet op de vraag reageert. |
| 93 | Geen antwoord van gebruiker (gewaarschuwd voor gebruiker) | De bestemming reageert op het aansluitingsverzoek maar heeft de verbinding niet binnen de voorgeschreven tijd voltooid. Het probleem is aan het uiteinde van de verbinding. |
| 95 | Aanvraag verworpen | De bestemming kan de oproep accepteren maar verworpen om een onbekende reden. |
| 9 C | Ongeldige nummerindeling | De verbinding kon niet tot stand worden gebracht omdat het doeladres in een niet-herkenbaar formaat werd aangeboden of omdat het doeladres onvolledig was. |
| 9 | Normaal, niet gespecificeerd | meldt het optreden van een normale gebeurtenis wanneer geen standaardoorzaak van toepassing is. Geen actie vereist. |
| A2 | Geen circuit/kanaal beschikbaar | De verbinding kan niet worden gevestigd omdat geen geschikt kanaal beschikbaar is om de vraag te nemen. |
| A6 | Netwerk buiten bedrijf | De bestemming kan niet worden bereikt omdat het netwerk niet goed werkt en de voorwaarde kan langere tijd duren. Een onmiddellijke poging om opnieuw verbinding te maken zal waarschijnlijk niet slagen. |
| AC | Gevonden circuit/kanaal niet beschikbaar | De externe apparatuur kan het gevraagde kanaal niet om een onbekende reden leveren. Dit kan een tijdelijk probleem zijn. |
| B2 | Gevraagde faciliteit niet ingetekend | De apparatuur op afstand ondersteunt de gevraagde aanvullende service uitsluitend via abonnement. Dit is vaak een verwijzing naar langeafstandsdiensten. |
| B9 | Niet toegestaan | De gebruiker heeft gevraagd om een gebruikersinterface die het netwerk biedt, maar de gebruiker mag het niet gebruiken. Dit kan een abonnementsprobleem zijn. |
| D8 | Incompatibele bestemming | Geeft aan dat een poging is gedaan om verbinding te maken met niet-ISDN apparatuur. Bijvoorbeeld, aan een analoge lijn. |
| E0 | Verplicht informatie element ontbreekt | De ontvangende apparatuur ontving een bericht dat geen van de verplichte informatie-elementen bevatte. Dit is meestal een gevolg van een D-kanaal-fout. Als deze fout systematisch optreedt, rapporteert u dit aan de ISDN-serviceprovider. |
| E4 | Ongeldige inhoud van informatie-element | De afstandsapparatuur heeft een bericht ontvangen met ongeldige informatie over het informatie-element. Dit is meestal een gevolg van een D-kanaal-fout. |
CAS uitgaande bellen
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 hiervoor debug dialer gebeurtenissen. Raadpleeg Bediening van snelkiezer controleren.
Voordat er een oproep kan worden geplaatst, moet er een modem worden toegewezen voor de oproep. Om dit proces, en de daaropvolgende vraag, te bekijken, gebruikt u de volgende debug-opdrachten:
-
modem reinigen
-
dobug van modemcsm
-
afkappen
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# router#modem-mgmt csm no-debug-rbs neat msg at slot 0: debug-rbs is off
Opmerking: Het afluisteren van deze informatie op een AS5800 vereist verbinding met de boomwerkkaart. 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 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. Raadpleeg Hoofdstuk 15 voor informatie over probleemoplossing in T1.
PPP-probleemoplossing
Problemen oplossen het PPP gedeelte van een verbinding begint wanneer u weet dat de verbinding met de knop, ISDN of asynchrone, met succes bevestigt.
Het is belangrijk om te begrijpen wat een succesvolle debug PPP-volgorde eruit ziet voordat u de onderhandeling over PPP-oplossingen besleept. Op deze manier bespaart het vergelijken van een defecte PPP debug sessie tegen een succesvol voltooide debug PPP-reeks u tijd en moeite.
Na is een voorbeeld van een succesvolle PPP-reeks. Zie PPP LCP-onderhandelingsdetails voor een gedetailleerde beschrijving van de uitvoervelden.
Montecito# Mar 13 10:57:13.415: %LINK-3-UPDOWN: Interface Async1, changed state to up Mar 13 10:57:15.415: As1 LCP: O CONFREQ [ACKrcvd] id 2 len 25 Mar 13 10:57:15.415: As1 LCP: ACCM 0x000A0000 (0x0206000A0000) Mar 13 10:57:15.415: As1 LCP: AuthProto CHAP (0x0305C22305) Mar 13 10:57:15.415: As1 LCP: MagicNumber 0x1084F0A2 (0x05061084F0A2) Mar 13 10:57:15.415: As1 LCP: PFC (0x0702) Mar 13 10:57:15.415: As1 LCP: ACFC (0x0802) Mar 13 10:57:15.543: As1 LCP: I CONFACK [REQsent] id 2 len 25 Mar 13 10:57:15.543: As1 LCP: ACCM 0x000A0000 (0x0206000A0000) Mar 13 10:57:15.543: As1 LCP: AuthProto CHAP (0x0305C22305) Mar 13 10:57:15.543: As1 LCP: MagicNumber 0x1084F0A2 (0x05061084F0A2) Mar 13 10:57:15.543: As1 LCP: PFC (0x0702) Mar 13 10:57:15.547: As1 LCP: ACFC (0x0802) Mar 13 10:57:16.919: As1 LCP: I CONFREQ [ACKrcvd] id 4 len 23 Mar 13 10:57:16.919: As1 LCP: ACCM 0x000A0000 (0x0206000A0000) Mar 13 10:57:16.919: As1 LCP: MagicNumber 0x001327B0 (0x0506001327B0) Mar 13 10:57:16.919: As1 LCP: PFC (0x0702) Mar 13 10:57:16.919: As1 LCP: ACFC (0x0802) Mar 13 10:57:16.919: As1 LCP: Callback 6 (0x0D0306) Mar 13 10:57:16.919: As1 LCP: O CONFREJ [ACKrcvd] id 4 len 7 Mar 13 10:57:16.919: As1 LCP: Callback 6 (0x0D0306) Mar 13 10:57:17.047: As1 LCP: I CONFREQ [ACKrcvd] id 5 len 20 Mar 13 10:57:17.047: As1 LCP: ACCM 0x000A0000 (0x0206000A0000) Mar 13 10:57:17.047: As1 LCP: MagicNumber 0x001327B0 (0x0506001327B0) Mar 13 10:57:17.047: As1 LCP: PFC (0x0702) Mar 13 10:57:17.047: As1 LCP: ACFC (0x0802) Mar 13 10:57:17.047: As1 LCP: O CONFACK [ACKrcvd] id 5 len 20 Mar 13 10:57:17.047: As1 LCP: ACCM 0x000A0000 (0x0206000A0000) Mar 13 10:57:17.047: As1 LCP: MagicNumber 0x001327B0 (0x0506001327B0) Mar 13 10:57:17.047: As1 LCP: PFC (0x0702) Mar 13 10:57:17.047: As1 LCP: ACFC (0x0802) Mar 13 10:57:17.047: As1 LCP: State is Open Mar 13 10:57:17.047: As1 PPP: Phase is AUTHENTICATING, by this end Mar 13 10:57:17.047: As1 CHAP: O CHALLENGE id 1 len 28 from "Montecito" Mar 13 10:57:17.191: As1 CHAP: I RESPONSE id 1 len 30 from "Goleta" Mar 13 10:57:17.191: As1 CHAP: O SUCCESS id 1 len 4 Mar 13 10:57:17.191: As1 PPP: Phase is UP Mar 13 10:57:17.191: As1 IPCP: O CONFREQ [Closed] id 1 len 10 Mar 13 10:57:17.191: As1 IPCP: Address 172.22.66.23 (0x0306AC164217) Mar 13 10:57:17.303: As1 IPCP: I CONFREQ [REQsent] id 1 len 40 Mar 13 10:57:17.303: As1 IPCP: CompressType VJ 15 slots CompressSlotID (0x0206002D0F01) Mar 13 10:57:17.303: As1 IPCP: Address 0.0.0.0 (0x030600000000) Mar 13 10:57:17.303: As1 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000) Mar 13 10:57:17.303: As1 IPCP: PrimaryWINS 0.0.0.0 (0x820600000000) Mar 13 10:57:17.303: As1 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000) Mar 13 10:57:17.303: As1 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000) Mar 13 10:57:17.303: As1 IPCP: O CONFREJ [REQsent] id 1 len 22 Mar 13 10:57:17.303: As1 IPCP: CompressType VJ 15 slots CompressSlotID (0x0206002D0F01) Mar 13 10:57:17.303: As1 IPCP: PrimaryWINS 0.0.0.0 (0x820600000000) Mar 13 10:57:17.303: As1 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000) Mar 13 10:57:17.319: As1 CCP: I CONFREQ [Not negotiated] id 1 len 15 Mar 13 10:57:17.319: As1 CCP: MS-PPC supported bits 0x00000001 (0x120600000001) Mar 13 10:57:17.319: As1 CCP: Stacker history 1 check mode EXTENDED (0x1105000104) Mar 13 10:57:17.319: As1 LCP: O PROTREJ [Open] id 3 len 21 protocol CCP Mar 13 10:57:17.319: As1 LCP: (0x80FD0101000F12060000000111050001) Mar 13 10:57:17.319: As1 LCP: (0x04) Mar 13 10:57:17.319: As1 IPCP: I CONFACK [REQsent] id 1 len 10 Mar 13 10:57:17.319: As1 IPCP: Address 172.22.66.23 (0x0306AC164217) Mar 13 10:57:18.191: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async1, changed state to up Mar 13 10:57:19.191: As1 IPCP: TIMEout: State ACKrcvd Mar 13 10:57:19.191: As1 IPCP: O CONFREQ [ACKrcvd] id 2 len 10 Mar 13 10:57:19.191: As1 IPCP: Address 172.22.66.23 (0x0306AC164217) Mar 13 10:57:19.315: As1 IPCP: I CONFACK [REQsent] id 2 len 10 Mar 13 10:57:19.315: As1 IPCP: Address 172.22.66.23 (0x0306AC164217) Mar 13 10:57:20.307: As1 IPCP: I CONFREQ [ACKrcvd] id 2 len 34 Mar 13 10:57:20.307: As1 IPCP: Address 0.0.0.0 (0x030600000000) Mar 13 10:57:20.307: As1 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000) Mar 13 10:57:20.307: As1 IPCP: PrimaryWINS 0.0.0.0 (0x820600000000) Mar 13 10:57:20.307: As1 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000) Mar 13 10:57:20.307: As1 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000) Mar 13 10:57:20.307: As1 IPCP: O CONFREJ [ACKrcvd] id 2 len 16 Mar 13 10:57:20.307: As1 IPCP: PrimaryWINS 0.0.0.0 (0x820600000000) Mar 13 10:57:20.307: As1 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000) Mar 13 10:57:20.419: As1 IPCP: I CONFREQ [ACKrcvd] id 3 len 22 Mar 13 10:57:20.419: As1 IPCP: Address 0.0.0.0 (0x030600000000) Mar 13 10:57:20.419: As1 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000) Mar 13 10:57:20.419: As1 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000) Mar 13 10:57:20.419: As1 IPCP: O CONFNAK [ACKrcvd] id 3 len 22 Mar 13 10:57:20.419: As1 IPCP: Address 10.1.1.1 (0x03060A010101) Mar 13 10:57:20.419: As1 IPCP: PrimaryDNS 171.68.10.70 (0x8106AB440A46) Mar 13 10:57:20.419: As1 IPCP: SecondaryDNS 171.68.10.140 (0x8306AB440A8C) Mar 13 10:57:20.543: As1 IPCP: I CONFREQ [ACKrcvd] id 4 len 22 Mar 13 10:57:20.543: As1 IPCP: Address 10.1.1.1 (0x03060A010101) Mar 13 10:57:20.547: As1 IPCP: PrimaryDNS 171.68.10.70 (0x8106AB440A46) Mar 13 10:57:20.547: As1 IPCP: SecondaryDNS 171.68.10.140 (0x8306AB440A8C) Mar 13 10:57:20.547: As1 IPCP: O CONFACK [ACKrcvd] id 4 len 22 Mar 13 10:57:20.547: As1 IPCP: Address 10.1.1.1 (0x03060A010101) Mar 13 10:57:20.547: As1 IPCP: PrimaryDNS 171.68.10.70 (0x8106AB440A46) Mar 13 10:57:20.547: As1 IPCP: SecondaryDNS 171.68.10.140 (0x8306AB440A8C) Mar 13 10:57:20.547: As1 IPCP: State is Open Mar 13 10:57:20.551: As1 IPCP: Install route to 10.1.1.1
N.B.: Uw specificaties kunnen in een andere indeling worden weergegeven. Dit voorbeeld toont het nieuwere debugging van PPP uitvoerformaat die werd gewijzigd in IOS versie 11.2(8). Zie Hoofdstuk 16 voor een voorbeeld van het zuiveren van PPP met de oudere versies van IOS.
PPP LCP-onderhandelingsdetails
| Timer | Beschrijving |
|---|---|
| 10:57:15.415 | Uitgaande configuratieaanvraag (O CONFREQ). NAS stuurt een uitgaand PPP-configuratiepakket naar de client. |
| 10:57:15.543 | Inkomend configuratie ontvangstbevestiging (I CONFACK). De client erkent het PPP-verzoek van Montecito. |
| 10:57:16.919 | Inkomend configuratieverzoek (I CONFREQ). De klant wil onderhandelen over het terugbelprotocol. |
| 10:57:16.919 | Uitgaande configuratie wijst af (O CONFREJ). De NAS wijst de callback optie af. |
| 10:57:17.047 | Inkomend configuratieverzoek (I CONFREQ). De klant vraagt om een nieuwe reeks opties. Merk op dat Microsoft Terugbellen deze keer niet is gevraagd. |
| 10:57:17.047 | Uitgaande configuratie ontvangstbevestiging (O CONFACK). De NAS accepteert de nieuwe reeks opties. |
| 10:57:17.047 | De PPP LCP-onderhandeling is voltooid. De LCP-status is "Open". Beide partijen hebben het configuratieverzoek van de andere kant (CONFREQ) erkend. |
| 10:57:17:047 tot 10:57:17:191 | PPP-verificatie is voltooid. Nadat de LCP onderhandelt, begint de authenticatie. De verificatie moet plaatsvinden voordat er netwerkprotocollen, zoals IP, worden geleverd. Beide partijen authentiseren met de methode die tijdens LCP is overeengekomen. Montecito authenticeert de client met CHAP. |
| 10:57:20.551 | De status is beschikbaar voor IP Control Protocol (IPCP). Er wordt onderhandeld over een route die is geïnstalleerd voor de IPCP-peer, die IP-adres 1.1.1 krijgt toegewezen. |
Link Control-protocol
Er worden twee soorten problemen doorgaans aangetroffen tijdens de LCP-onderhandeling.
Het eerste gebeurt wanneer één peer configuratieverzoeken indient die de andere peer niet kan of zal erkennen. Terwijl dit een frequent voorkomen is, kan het een probleem zijn als de verzoeker op de parameter aanhoudt. Een typisch voorbeeld is bij het onderhandelen over AUTHTYPE (ook bekend als "AuthProto"). Bijvoorbeeld, veel toegangsservers worden gevormd om slechts CHAP voor authenticatie te accepteren. Als de beller is ingesteld om alleen PAP-verificatie uit te voeren, worden CONFREQ's en CONFNAK's uitgewisseld totdat een peer of de andere de verbinding laat vallen.
BR0:1 LCP: I CONFREQ [ACKrcvd] id 66 len 14 BR0:1 LCP: AuthProto PAP (0x0304C023) BR0:1 LCP: MagicNumber 0xBC6B9F91 (0x0506BC6B9F91) BR0:1 LCP: O CONFNAK [ACKrcvd] id 66 len 9 BR0:1 LCP: AuthProto CHAP (0x0305C22305) BR0:1 LCP: I CONFREQ [ACKrcvd] id 67 len 14 BR0:1 LCP: AuthProto PAP (0x0304C023) BR0:1 LCP: MagicNumber 0xBC6B9F91 (0x0506BC6B9F91) BR0:1 LCP: O CONFNAK [ACKrcvd] id 67 len 9 BR0:1 LCP: AuthProto CHAP (0x0305C22305) BR0:1 LCP: I CONFREQ [ACKrcvd] id 68 len 14 BR0:1 LCP: AuthProto PAP (0x0304C023) BR0:1 LCP: MagicNumber 0xBC6B9F91 (0x0506BC6B9F91) BR0:1 LCP: O CONFNAK [ACKrcvd] id 68 len 9 BR0:1 LCP: AuthProto CHAP (0x0305C22305) ... ...
Het tweede type probleem in LCP is wanneer alleen uitgaande CONFREQ's op één of beide peers worden gezien, zoals in het onderstaande voorbeeld. Dit is meestal het resultaat van wat wordt aangeduid als een snelheidsfout bij de onderste laag. Deze voorwaarde kan in of async of ISDN DDR voorkomen.
Jun 10 19:57:59.768: As5 PPP: Phase is ESTABLISHING, Active Open Jun 10 19:57:59.768: As5 LCP: O CONFREQ [Closed] id 64 len 25 Jun 10 19:57:59.768: As5 LCP: ACCM 0x000A0000 (0x0206000A0000) Jun 10 19:57:59.768: As5 LCP: AuthProto CHAP (0x0305C22305) Jun 10 19:57:59.768: As5 LCP: MagicNumber 0x5779D9D2 (0x05065779D9D2) Jun 10 19:57:59.768: As5 LCP: PFC (0x0702) Jun 10 19:57:59.768: As5 LCP: ACFC (0x0802) Jun 10 19:58:01.768: As5 LCP: TIMEout: State REQsent Jun 10 19:58:01.768: As5 LCP: O CONFREQ [REQsent] id 65 len 25 Jun 10 19:58:01.768: As5 LCP: ACCM 0x000A0000 (0x0206000A0000) Jun 10 19:58:01.768: As5 LCP: AuthProto CHAP (0x0305C22305) Jun 10 19:58:01.768: As5 LCP: MagicNumber 0x5779D9D2 (0x05065779D9D2) Jun 10 19:58:01.768: As5 LCP: PFC (0x0702) Jun 10 19:58:01.768: As5 LCP: ACFC (0x0802). Jun 10 19:58:03.768: As5 LCP: TIMEout: State REQsent Jun 10 19:58:03.768: As5 LCP: O CONFREQ [REQsent] id 66 len 25 Jun 10 19:58:03.768: As5 LCP: ACCM 0x000A0000 (0x0206000A0000) Jun 10 19:58:03.768: As5 LCP: AuthProto CHAP (0x0305C22305) Jun 10 19:58:03.768: As5 LCP: MagicNumber 0x5779D9D2 (0x05065779D9D2) Jun 10 19:58:03.768: As5 LCP: PFC (0x0702) Jun 10 19:58:03.768: As5 LCP: ACF.C (0x0802) Jun 10 19:58:05.768: As5 LCP: TIMEout: State REQsent Jun 10 19:58:05.768: As5 LCP: O CONFREQ [REQsent] id 67 len 25 !--- This repeats every two seconds until: Jun 10 19:58:19.768: As5 LCP: O CONFREQ [REQsent] id 74 len 25 Jun 10 19:58:19.768: As5 LCP: ACCM 0x000A0000 (0x0206000A0000) Jun 10 19:58:19.768: As5 LCP: AuthProto CHAP (0x0305C22305) Jun 10 19:58:19.768: As5 LCP: MagicNumber 0x5779D9D2 (0x05065779D9D2) Jun 10 19:58:19.768: As5 LCP: PFC (0x0702) Jun 10 19:58:19.768: As5 LCP: ACFC (0x0802) Jun 10 19:58:21.768: As5 LCP: TIMEout: State REQsent Jun 10 19:58:21.768: TTY5: Async Int reset: Dropping DTR
Als de verbinding asynchrone is, is de waarschijnlijke oorzaak een snelle mismatch tussen de router en zijn modem. Dit is meestal een gevolg van het niet vergrendelen van de DTE-snelheid van de modem met de ingestelde snelheid van de TTY-lijn. Het probleem kan op een van beide of beide peers gevonden worden, dus controleer beide. Raadpleeg Modem Kan geen gegevens eerder in dit hoofdstuk verzenden of ontvangen.
Als de symptomen worden gezien wanneer de verbinding over ISDN is, is het probleem waarschijnlijk dat het ene peer zich aansluit bij 56K terwijl het andere 64K is. Hoewel deze aandoening zelden voorkomt, gebeurt dit wel. Het probleem kan één of beide zijn, of mogelijk het telefoonbedrijf. Gebruik debug ISDN Q931 en onderzoek de SETUP-berichten op elk van de peers. De van één peer verstuurde draaiercapaciteit moet overeenkomen met de draagkracht aan toonder die te zien is in het SETUP-bericht dat op de andere peer wordt ontvangen. Als mogelijke oplossing, moet u de draaisnelheid 56K of 64K configureren in de dialerkaart van het interfaceniveau of in het dialer van het commando dat is ingesteld onder een map-klasse.
*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
Deze situatie is er een die een oproep naar de Cisco TAC kan rechtvaardigen. Verzamel de volgende output van beide peers voordat u de TAC aanvraagt:
-
toonaangevend in werking stellen
-
show version
-
debug van ISDN Q931
-
isdn gebeurtenissen debug
-
debug van PPP-onderhandeling
Verificatie
Ontbrekende verificatie is de meest gebruikelijke reden voor een PPP-fout. Misingesteld of verkeerd afgesloten gebruikersnamen en wachtwoorden maken foutmeldingen in debug uitvoer.
Het volgende voorbeeld toont aan dat de gebruikersnaam Goleta geen toestemming heeft om in te bellen op de NAS, die geen lokale gebruikersnaam heeft ingesteld voor deze gebruiker. Om het probleem op te lossen, gebruikt u de opdracht van het wachtwoord van de gebruikersnaam om de gebruikersnaam "Goleta" toe te voegen aan de lokale AAA-database van NAS:
Mar 13 11:01:42.399: As2 LCP: State is Open Mar 13 11:01:42.399: As2 PPP: Phase is AUTHENTICATING, by this end Mar 13 11:01:42.399: As2 CHAP: O CHALLENGE id 1 len 28 from "Montecito" Mar 13 11:01:42.539: As2 CHAP: I RESPONSE id 1 len 30 from "Goleta" Mar 13 11:01:42.539: As2 CHAP: Unable to validate Response. Username Goleta not found Mar 13 11:01:42.539: As2 CHAP: O FAILURE id 1 len 26 msg is "Authentication failure" Mar 13 11:01:42.539: As2 PPP: Phase is TERMINATING
Het volgende voorbeeld toont aan dat de gebruikersnaam "Goleta" op de NAS is ingesteld. De wachtwoordvergelijking is echter niet geslaagd. Om dit probleem op te lossen, gebruikt u de opdracht Wachtwoord voor gebruikersnaam om het juiste inlogwachtwoord voor Goleta op te geven:
Mar 13 11:04:06.843: As3 LCP: State is Open Mar 13 11:04:06.843: As3 PPP: Phase is AUTHENTICATING, by this end Mar 13 11:04:06.843: As3 CHAP: O CHALLENGE id 1 len 28 from "Montecito" Mar 13 11:04:06.987: As3 CHAP: I RESPONSE id 1 len 30 from "Goleta" Mar 13 11:04:06.987: As3 CHAP: O FAILURE id 1 len 25 msg is "MD/DES compare failed" Mar 13 11:04:06.987: As3 PPP: Phase is TERMINATING
Voor meer informatie over PAP-verificatie raadpleegt u PPP Wachtwoord-verificatie (PAP) configureren en probleemoplossing.
Netwerkbeheerprotocol
Nadat de peers de vereiste authenticatie succesvol hebben uitgevoerd, beweegt de onderhandeling in de NCP fase. Als beide peers goed zijn geconfigureerd zullen de NCP-onderhandeling er als het volgende voorbeeld uitzien dat toont dat een client-PC in- en onderhandelt met een NAS:
solvang# show debug Generic IP: IP peer address activity debugging is on PPP: PPP protocol negotiation debugging is on *Mar 1 21:35:04.186: As4 PPP: Phase is UP *Mar 1 21:35:04.190: As4 IPCP: O CONFREQ [Not negotiated] id 1 len 10 *Mar 1 21:35:04.194: As4 IPCP: Address 10.1.2.1 (0x03060A010201) *Mar 1 21:35:04.282: As4 IPCP: I CONFREQ [REQsent] id 1 len 28 *Mar 1 21:35:04.282: As4 IPCP: CompressType VJ 15 slots CompressSlotID (0x0206002D0F01) *Mar 1 21:35:04.286: As4 IPCP: Address 0.0.0.0 (0x030600000000) *Mar 1 21:35:04.290: As4 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000) *Mar 1 21:35:04.298: As4 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000) *Mar 1 21:35:04.306: As4 IPCP: O CONFREJ [REQsent] id 1 len 10 *Mar 1 21:35:04.310: As4 IPCP: CompressType VJ 15 slots CompressSlotID (0x0206002D0F01) *Mar 1 21:35:04.314: As4 CCP: I CONFREQ [Not negotiated] id 1 len 15 *Mar 1 21:35:04.318: As4 CCP: MS-PPC supported bits 0x00000001 (0x120600000001) *Mar 1 21:35:04.318: As4 CCP: Stacker history 1 check mode EXTENDED (0x1105000104) *Mar 1 21:35:04.322: As4 LCP: O PROTREJ [Open] id 3 len 21 protocol CCP *Mar 1 21:35:04.326: As4 LCP: (0x80FD0101000F12060000000111050001) *Mar 1 21:35:04.330: As4 LCP: (0x04) *Mar 1 21:35:04.334: As4 IPCP: I CONFACK [REQsent] id 1 len 10 *Mar 1 21:35:04.338: As4 IPCP: Address 10.1.2.1 (0x03060A010201) *Mar 1 21:35:05.186: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async4, changed state to up *Mar 1 21:35:07.274: As4 IPCP: I CONFREQ [ACKrcvd] id 2 len 22 *Mar 1 21:35:07.278: As4 IPCP: Address 0.0.0.0 (0x030600000000) *Mar 1 21:35:07.282: As4 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000) *Mar 1 21:35:07.286: As4 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000) *Mar 1 21:35:07.294: As4 IPCP: O CONFNAK [ACKrcvd] id 2 len 22 *Mar 1 21:35:07.298: As4 IPCP: Address 10.1.2.2 (0x03060A010202) *Mar 1 21:35:07.302: As4 IPCP: PrimaryDNS 10.2.2.3 (0x81060A020203) *Mar 1 21:35:07.310: As4 IPCP: SecondaryDNS 10.2.3.1 (0x83060A020301) *Mar 1 21:35:07.426: As4 IPCP: I CONFREQ [ACKrcvd] id 3 len 22 *Mar 1 21:35:07.430: As4 IPCP: Address 10.1.2.2 (0x03060A010202) *Mar 1 21:35:07.434: As4 IPCP: PrimaryDNS 10.2.2.3 (0x81060A020203) *Mar 1 21:35:07.442: As4 IPCP: SecondaryDNS 10.2.3.1 (0x83060A020301) *Mar 1 21:35:07.446: ip_get_pool: As4: validate address = 10.1.2.2 *Mar 1 21:35:07.450: ip_get_pool: As4: using pool default *Mar 1 21:35:07.450: ip_get_pool: As4: returning address = 10.1.2.2 *Mar 1 21:35:07.454: set_ip_peer_addr: As4: address = 10.1.2.2 (3) is redundant *Mar 1 21:35:07.458: As4 IPCP: O CONFACK [ACKrcvd] id 3 len 22 *Mar 1 21:35:07.462: As4 IPCP: Address 10.1.2.2 (0x03060A010202) *Mar 1 21:35:07.466: As4 IPCP: PrimaryDNS 10.2.2.3 (0x81060A020203) *Mar 1 21:35:07.474: As4 IPCP: SecondaryDNS 10.2.3.1 (0x83060A020301) *Mar 1 21:35:07.478: As4 IPCP: State is Open *Mar 1 21:35:07.490: As4 IPCP: Install route to 10.1.2.2
PPP NCP-onderhandelingsdetails
| Timer | Beschrijving |
|---|---|
| 21:35:04.190 | Uitgaande configuratieaanvraag (O CONFREQ). NAS stuurt een uitgaand PPP-configuratiescherm met zijn IP-adres naar de peer. |
| 21:35:04.282 | Inkomend CONFREQ. De peer vraagt om VJ headercompressie te doen. Het heeft een IP-adres voor zichzelf nodig, evenals adressen van de primaire en secundaire DNS-servers. |
| 21:35:04.306 | Uitgaande Config-afstoting (CONFREJ). VJ-headercompressie is verworpen. |
| 21:35:04:314 tot 21:35 | De peer stuurt een verzoek tot uitvoering van een protocol voor de controle op compressie. het gehele protocol wordt door de NAS verworpen door middel van een PROTREJ-bericht. De peer moet niet proberen om CCP (en ook niet) opnieuw uit te proberen. |
| 21:35:04.334 | De peer erkent het IP-adres van de NAS met een CONFACK. |
| 21:35:07.274 | Inkomend CONFREQ. De peer vraagt niet langer om VJ headercompressie te doen, maar heeft nog steeds een IP adres nodig voor zichzelf, evenals adressen van de primaire en secundaire DNS servers. |
| 21:35:07.294 | NAS stuurt een CONFNAK met het adres dat hij wil gebruiken en adressen van de primaire en secundaire DNS-servers. |
| 21:35:07.426 | De peer stuurt de adressen terug naar de NAS; een poging om te bevestigen dat de adressen naar behoren zijn ontvangen. |
| 21:35:07.458 | De NAS erkent de adressen met een CONFACK. |
| 21:35:07.478 | Elke kant van de verbinding die een CONFACK heeft afgegeven, is de onderhandeling voltooid. De opdracht toont interfaces Async4 op de NAS toont "IPCP: Open". |
| 21:35:07.490 | Een host-route naar de externe peer wordt geïnstalleerd in de routingtabel van NAS. |
Het is mogelijk voor de peers om tegelijkertijd te onderhandelen over meer dan één Layer 3 protocol. Het is bijvoorbeeld niet ongewoon dat IP en IPX worden onderhandeld. Het ene protocol kan ook succesvol onderhandelen, terwijl het andere dat niet doet.
NCP voor probleemoplossing
Alle problemen die zich tijdens NCP-onderhandeling voordoen, kunnen doorgaans worden getraceerd naar de configuraties van de onderhandelingspartners. Als de PPP-onderhandeling tijdens de NCP-fase mislukt, raadpleegt u de volgende stappen:
-
Controleer de configuratie van het interfaceprotocol
Onderzoek de output van het bevoorrechte exec bevel tonen in werking gesteld-wijken. Controleer dat de interface is ingesteld ter ondersteuning van het protocol dat u via de verbinding wilt uitvoeren.
-
Interface-adres controleren
Bevestig dat de interface in kwestie een adres heeft ingesteld. Als u ip ongenummerd gebruikt [interface-naam] of ipx ppp-client loopback [number], zorg er dan voor dat de genoemde interface met een adres wordt geconfigureerd.
-
Controleer de beschikbaarheid van clientadres
Als de NAS een IP-adres aan de beller moet geven, zorg er dan voor dat dit adres beschikbaar is. Het IP-adres dat aan de beller moet worden afgegeven, kan op een van de volgende manieren worden verkregen:
-
Lokaal configureren op de interface. Controleer de interfaceconfiguratie voor de opdracht peer default ip-adres a.b.c.d. In praktijk dient deze methode alleen te worden gebruikt op interfaces die verbindingen van één enkele beller accepteren, zoals op een asynchrone (niet een groep-async) interface.
-
Adres pool lokaal ingesteld op de NAS. De interface moet de opdracht peer standaard IP-adrespool hebben [poolnaam]. Daarnaast moet de pool op systeemniveau worden gedefinieerd met de opdracht ip lokale pool [poolnaam] [eerste adres] [laatste adres]. Het bereik van de adressen die in de pool worden gedefinieerd moet groot genoeg zijn om evenveel gelijktijdig aangesloten opbellers te kunnen ontvangen als de NAS in staat is.
-
DHCP-server. De NAS interface moet worden geconfigureerd met het standaard IP-adres van de opdracht dhcp. Bovendien moet de NAS zo worden geconfigureerd dat hij naar een DHCP-server wijst met de IP-dhcp-server [adres].
-
AAA. Als u TACACS+ of RADIUS voor goedkeuring gebruikt, kan de AAA server worden geconfigureerd om een specifiek IP-adres aan een bepaalde beller te geven telkens wanneer de caller verbinding maakt. Zie Hoofdstuk 16 voor meer informatie.
-
-
Controleer de configuratie van het serveradres
Om de geconfigureerde adressen van de servers van de Naam van het Domein of van Windows NT-servers in antwoord op BOOTP-verzoeken terug te geven, zorg ervoor dat de opdrachten async-bootp dns-server [adres] en async-bootp nbns-server [adres] zijn geconfigureerd.
Opmerking: terwijl het commando async-bootp subtype-masker [masker] op de NAS kan worden ingesteld, zal het subnetmasker niet tussen de NAS en een PPP inbel client-PC worden onderhandeld. Vanwege de aard van point-to-point verbindingen gebruikt de client automatisch het IP-adres van de NAS (geleerd tijdens IPCP-onderhandeling) als de standaardgateway. Het subnetmasker is niet nodig in dat punt-tot-punt milieu. De PC weet dat als het doeladres niet overeenkomt met het lokale adres, het pakket verzonden moet worden naar de standaardgateway (NAS), die altijd via de PPP-link wordt bereikt.
Voordat u het Cisco Systems TAC-team belt
Voordat u het Cisco Systems Technical Assistance Center (TAC) belt, moet u dit hoofdstuk doorlezen en de acties voltooien die voor het probleem van uw systeem zijn voorgesteld.
U kunt bovendien het volgende doen en de resultaten documenteren zodat u beter kunt assisteren:
Voor alle problemen, verzamel de output van show in werking stellen-configuratie en toon versie. Zorg ervoor dat de opdracht service timestamps datetime msec is in de configuratie.
Verzamel voor DDR-problemen het volgende:
-
dialerkaart tonen
-
dialer debug
-
debug van PPP-onderhandeling
-
debug van PPP-verificatie
Als ISDN erbij betrokken is, verzamelt u:
-
ISDN-status tonen
-
debug van ISDN Q931
-
isdn gebeurtenissen debug
Als er modems betrokken zijn, verzamel dan:
-
tonen lijnen
-
tonen lijn [x]
-
modem tonen (als er geïntegreerde modems betrokken zijn)
-
toon modemversie (indien er geïntegreerde modems bij betrokken zijn)
-
modem reinigen
-
debug csm van modems (indien er geïntegreerde modems bij betrokken zijn)
-
debug chat (als een DDR-scenario)
Als T1s of PRI’ s betrokken zijn, verzamel dan:
-
demonstratiecontroller t1
Gerelateerde informatie
- T1/E1-pagina voor probleemoplossing
- Cisco IOS-handleiding voor kiesoplossingen
- De T1/E1-interface bewaken en onderhouden
- PPP-onderhandeling voor probleemoplossing
- Modules voor probleemoplossing
- Opdrachten voor modem
- ISDN-probleemoplossing
- T1 PRI-probleemoplossing
- Technische ondersteuning en documentatie – Cisco Systems
FeedbackContact Cisco
- Een ondersteuningscase openen
- (Vereist een Cisco-servicecontract)