ISDN BRI-stromen voor probleemoplossing
Inhoud
Inleiding
Dit document helpt u bij het oplossen van de toegang tot ISDN Basic Rate Interface (BRI). In het stroomschema en de steekproefuitvoer die hieronder wordt weergegeven, hebben we een ISDN BRI verbinding met een andere die Kiezerprofielen gebruikt ingesteld. Dezelfde stappen voor het oplossen van problemen zijn echter van toepassing op verbindingen met andere routers (zoals bijkantoren) en bij gebruik van Verouderde Dial-on-Demand Routing (DDR).
Opmerking: U kunt ook de Cisco Support Community gebruiken om u te helpen uw ISDN-probleem op te lossen.
Raadpleeg voor inleidende informatie over ISDN en DDR de audio-training in de Cisco Learning Connection.
Stroomdiagram
Klik op een onderstaande link om meer informatie over de optie te krijgen. Gebruik de achterknop van uw browser om naar dit stroomschema terug te keren.
Probleemoplossing: Inloggen en deze uitvindingen opnemen
U kunt met uw router of door de console kabel aan te sluiten op de seriële poort van uw PC, of door telnet te gebruiken.
Als u met uw router door de console moet verbinden, raadpleeg dan de toepassing Correct Terminal Emulator Settings voor Console Connections. Als uw router al is ingesteld voor connectiviteit op Ethernet en u wilt met uw router verbinden met behulp van telnet, gebruik eenvoudig een telnet client om aan het Ethernet IP-adres van de router te verbinden.
In elk geval (console of telnet), is het beter om een client te gebruiken die u toestaat om een geschiedenis van de uitvoer die tijdens de sessie ontvangen is te bewaren, aangezien u in uw debug uitvoer terug kunt moeten scrollen om bepaalde berichten te zoeken.
Activeert milliseconden op de debug uitvoer en logberichten. Voer desgevraagd het wachtwoord in dat op uw router is ingesteld en voer vervolgens de modus in:
router>enable Password: (enter the enable password) router# router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. router(config)#service timestamps debug datetime msec router(config)#service timestamps log datetime msec
Als u met telnet bent verbonden, typt u de volgende terminal:
router#terminal monitor router#
Hierna voert u de onderstaande opdrachten debug in:
router#debug isdn q931 ISDN Q931 packets debugging is on router#debug ppp negotiation PPP protocol negotiation debugging is on router#debug dialer packet Dial on demand packets debugging is on router#debug dialer Dial on demand events debugging is on router#debug ppp authentication PPP authentication debugging is on router#
Stel vervolgens het Pingel op de oproepende router in. Hieronder is een monster debug uitvoer van een succesvolle vraag. De verschillende fasen, zoals die in het stroomschema zijn aangegeven, worden gemarkeerd.
router#ping 194.183.201.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 194.183.201.1, timeout is 2 seconds: *Mar 1 00:06:36.383: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) ! -- The ping for 194.183.201.1 is interesting traffic and uses Dialer 1(Di1) *Mar 1 00:06:36.387: BR0 DDR: rotor dialout [priority] *Mar 1 00:06:36.391: BR0 DDR: Dialing cause ip (s=10.1.0.1, d=194.183.201.1) *Mar 1 00:06:36.395: BR0 DDR: Attempting to dial 8134 ! -- Number used to dial.
! -- This is configured using the dialer string or dialer map command
! -- If you do not see this message proceed to section
! -- Symptom: The Router Does Not Attempt to Dial *Mar 1 00:06:36.411: ISDN BR0: TX -> SETUP pd = 8 callref = 0x02 *Mar 1 00:06:36.415: Bearer Capability i = 0x8890 *Mar 1 00:06:36.423: Channel ID i = 0x83 *Mar 1 00:06:36.427: Called Party Number i = 0x80, '8134', Plan:Unknown, Type:Unknown *Mar 1 00:06:36.519: ISDN BR0: RX <- CALL_PROC pd = 8 callref = 0x82 *Mar 1 00:06:36.527: Channel ID i = 0x89 *Mar 1 00:06:36.727: ISDN BR0: RX <- CONNECT pd = 8 callref = 0x82 *Mar 1 00:06:36.743: ISDN BR0: TX -> CONNECT_ACK pd = 8 callref = 0x02 *Mar 1 00:06:36.751: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up ! -- ISDN Layer 3 CONNECT message and Link Up message ! -- If you do not see this message proceed to section ! -- Symptom: The ISDN Call Does Not Connect Successfully *Mar 1 00:06:36.767: BR0:1: interface must be fifo queue, force fifo *Mar 1 00:06:36.775: %DIALER-6-BIND: Interface BR0:1 bound to profile Di1 *Mar 1 00:06:36.787: BR0:1 PPP: Treating connection as a callout *Mar 1 00:06:36.791: BR0:1 PPP: Phase is ESTABLISHING, Active Open ! -- LCP negotiation begins *Mar 1 00:06:36.791: BR0:1 PPP: No remote authentication for call-out *Mar 1 00:06:36.795: BR0:1 LCP: O CONFREQ [Closed] id 3 len 10 *Mar 1 00:06:36.799: BR0:1 LCP: MagicNumber 0x0012586A (0x05060012586A) *Mar 1 00:06:36.859: BR0:1 LCP: I CONFREQ [REQsent] id 59 len 15 *Mar 1 00:06:36.863: BR0:1 LCP: AuthProto CHAP (0x0305C22305) *Mar 1 00:06:36.867: BR0:1 LCP: MagicNumber 0x10D36A4C (0x050610D36A4C) *Mar 1 00:06:36.871: BR0:1 LCP: O CONFACK [REQsent] id 59 len 15 *Mar 1 00:06:36.875: BR0:1 LCP: AuthProto CHAP (0x0305C22305) *Mar 1 00:06:36.875: BR0:1 LCP: MagicNumber 0x10D36A4C (0x050610D36A4C) *Mar 1 00:06:36.879: BR0:1 LCP: I CONFACK [ACKsent] id 3 len 10 *Mar 1 00:06:36.883: BR0:1 LCP: MagicNumber 0x0012586A (0x05060012586A) *Mar 1 00:06:36.887: BR0:1 LCP: State is Open ! -- LCP negotiation is complete. Any LCP state other than Open indicates
! -- that LCP negotiation has failed.
! -- If you do not see this message proceed to section
! -- Symptom: PPP LCP Phase Does Not Succeed *Mar 1 00:06:36.903: BR0:1 PPP: Phase is AUTHENTICATING, by the peer *Mar 1 00:06:36.907: BR0:1 CHAP: I CHALLENGE id 38 len 24 from "ISP" ! -- Incoming CHAP challenge *Mar 1 00:06:36.915: BR0:1 CHAP: Using alternate hostname XXXXX ! -- Using alternate hostname configured with ppp chap hostname command *Mar 1 00:06:36.915: BR0:1 CHAP: Username ISP not found *Mar 1 00:06:36.919: BR0:1 CHAP: Using default password ! -- Using password configured with ppp chap password command *Mar 1 00:06:36.923: BR0:1 CHAP: O RESPONSE id 38 len 26 from "XXXXX" ! -- Sending response from "XXXXX" which is the alternate hostname for the router *Mar 1 00:06:36.939: BR0:1 CHAP: I SUCCESS id 38 len 4 ! -- NAS has succesfully authenticated the router *Mar 1 00:06:36.943: BR0:1 PPP: Phase is UP ! -- PPP Authentication is successful ! -- PPP NCP (IPCP) negotiation begins *Mar 1 00:06:36.947: BR0:1 IPCP: O CONFREQ [Not negotiated] id 3 len 10 *Mar 1 00:06:36.951: BR0:1 IPCP: Address 0.0.0.0 (0x030600000000) ! -- This router does not have an address configured, so it sends a
! -- CONFREQ with the address 0.0.0.0. This tells the other peer to assign an address
! -- which is accomplished by the sending of a CONFNAK with the proper address. *Mar 1 00:06:36.955: BR0:1 IPCP: I CONFREQ [REQsent] id 26 len 10 *Mar 1 00:06:36.963: BR0:1 IPCP: Address 194.183.201.1 (0x0306C2B7C901) ! -- Incoming CONFREQ indicating the peer's IP address *Mar 1 00:06:36.967: BR0:1 IPCP: O CONFACK [REQsent] id 26 len 10 *Mar 1 00:06:36.971: BR0:1 IPCP: Address 194.183.201.1 (0x0306C2B7C901) ! -- The router accepts the peer's IP address
! -- (since it is not trying to assign one to the peer)
! -- Once the call is connected a route to this address will be installed *Mar 1 00:06:36.975: BR0:1 IPCP: I CONFNAK [ACKsent] id 3 len 10 *Mar 1 00:06:36.979: BR0:1 IPCP: Address 194.183.201.2 (0x0306C2B7C902) ! -- The peer CONFNAKs our initial Address request of 0.0.0.0
! -- It responds with the address that this router could use
! -- The NAS can assign this using the peer default ip address or dialer map command *Mar 1 00:06:36.983: BR0:1 IPCP: O CONFREQ [ACKsent] id 4 len 10 *Mar 1 00:06:36.987: BR0:1 IPCP: Address 194.183.201.2 (0x0306C2B7C902) ! -- This router requests the address previously suggested by the NAS *Mar 1 00:06:37.011: BR0:1 IPCP: I CONFACK [ACKsent] id 4 len 10 *Mar 1 00:06:37.015: BR0:1 IPCP: Address 194.183.201.2 (0x0306C2B7C902) ! -- NAS accepts the address requested by the client *Mar 1 00:06:37.015: BR0:1 IPCP: State is Open ! -- PPP NCP (IPCP) negotiation is complete ! -- If you do not see this message proceed to section
! -- Symptom: PPP NCP (IPCP) negotiation does not succeed *Mar 1 00:06:37.019: Di1 IPCP: Install negotiated IP interface address 194.183.201.2 *Mar 1 00:06:37.031: BR0:1 DDR: dialer protocol up *Mar 1 00:06:37.039: Di1 IPCP: Install route to 194.183.201.1 ! -- Route to peer is installed *Mar 1 00:06:37.943: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to up *Mar 1 00:06:38.383: Di1 DDR: ip (s=194.183.201.2, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) *Mar 1 00:06:38.427: Di1 DDR: ip (s=194.183.201.2, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) *Mar 1 00:06:38.471: Di1 DDR: ip (s=194.183.201.2, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) *Mar 1 00:06:38.515: Di1 DDR: ip (s=194.183.201.2, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) router# *Mar 1 00:06:42.783: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 8134 unknown router#
Terug naar het stroomschema voor de probleemoplossing
Probleemoplossing: Probeert de router te bellen?
Om te weten te komen of de router probeert om een vraag te plaatsen, controleer of u de volgende lijnen in de debug uitvoer van de oproepende router hebt:
*Mar 1 00:06:36.395: BR0 DDR: Attempting to dial 8134
In de debug uitvoer is 8134 het directory nummer van ISDN dat de router probeert te bellen. Dit nummer is gespecificeerd met de opdracht dialer string of dialer map.
Terug naar het stroomschema voor de probleemoplossing
Symptoom: De router probeert niet te bellen
Als uw router niet probeert te bellen, zijn er verschillende mogelijkheden:
helemaal geen debug-uitvoer
Als er helemaal geen debug uitvoer is, is dit zeer waarschijnlijk omdat het IP-pakket dat u verzenden niet eens naar de snelkiezerinterface wordt verzonden. De meest voorkomende oorzaken hiervan zijn:
- Controleer dat IP in de snelkiezerinterface is ingesteld. U dient een IP-adres op de dialerinterface te hebben of IP niet-genummerde interface te hebben (waar de interface een omhoog/omhoog interface is zoals Ethernet x, loopback x) of een IP-adres dat is overeengekomen (indien de client een IP-adres van de NAS krijgt). Als u legacy DDR gebruikt, dan moet het IP-adres op de fysieke interface worden ingesteld (bijvoorbeeld interface BRI 0).
- Controleer dat de opdracht ip-routing is ingesteld. Wanneer u naar uw configuratie kijkt die het tonen in werking stellen-configuratie bevel gebruikt, zou u niet de opdracht geen ip routing moeten zien.
- Controleer of er een statische route is, gericht in de dialer interface of volgende hop (indien dialer-kaarten worden gebruikt).
Het volgende voorbeeld (voor dialerprofiel) is een statische route voor 172.22.53.0/24 met volgende hopwijzer 1:
maui-soho-01(config)#ip route 172.22.53.0 255.255.255.0 dialer 1
Het volgende voorbeeld (voor erfenis DDR) is een statische route voor 172.22.53.0/24 met volgende hop 172.16.1.1. Het volgende hopadres moet het ip adres in het dialer plattegrond statement passen dat voor de kiestoon wordt gebruikt:
maui-soho-01(config)#ip route 172.22.53.0 255.255.255.0 172.16.1.1
- Controleer dat het dialoogvenster of de fysieke interface niet in de stand-by modus staat. Gebruik het X--X-opdracht van de interface tonen om er zeker van te zijn dat de interface in de state-up/up (spoofing) staat.
Als de interface administratief is neergezet, gebruikt u de opdracht no shutdown in de interfaceconfiguratiemodus.
Als de interface in stand-by staat is, dan is de dialer of BRI interface een back-up naar een verbinding die omhoog is. U kunt de opdracht back-upinterface verwijderen onder de primaire interface of de kabel uit de primaire interface trekken.
Er is een Debug-uitvoer maar er is geen "Proberen om te bellen"-bericht
In dit geval, is er waarschijnlijk een IP pakket dat aan de interface wordt routeerd, maar de router vergooit het en leidt niet tot de vraag om één of andere reden. Kijk naar de debug uitvoer om te weten te komen waarom de aanroep niet is gemaakt. Hieronder zie je wat voorbeelden van debug outputs en hun mogelijke redenen:
Voorbeeld 1
*Mar 13 10:43:50.253: Di1 DDR: ip (s=10.1.1.1, d=172.22.53.1), 100 bytes, outgoing uninteresting (list 101).
Het gegenereerde verkeer komt niet overeen met de interessante verkeersdefinitie. Wijzig bijvoorbeeld de toegangslijst 101.
Een eenvoudige interessante verkeersdefinitie zou zijn om al IP-verkeer toe te staan zoals in:
maui-soho-01(config)#dialer-list 1 protocol ip permit
Waarschuwing: Het markeren van al IP verkeer als interessant kan de verbinding van ISDN veroorzaken om voor onbepaalde tijd omhoog te blijven, vooral als u een routeringsprotocol of ander periodiek verkeer hebt. Stel de interessante verkeersdefinitie in op uw behoeften.
Raadpleeg de technologie voor het selecteren van documenten voor meer informatie over interessant verkeer: Overzichten en toelichtingen.
Voorbeeld 2
*Mar 1 00:07:22.255: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1), 100 bytes, outgoing uninteresting (no dialer-group defined).
Er is geen dialer-groep ingesteld op de dialerinterface. Voeg een dialer-groep toe zoals in het volgende voorbeeld:
interface Dialer1 dialer-group X
Opmerking: De waarde voor X moet dezelfde zijn die gebruikt wordt met de opdracht dialer-list.
Voorbeeld 3
*Mar 1 00:08:24.919: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1), 100 bytes, outgoing uninteresting (dialer-list 1 not defined).
Er is een dialer-group verklaring op de dialer interface, maar de bedoelde dialer-lijst bestaat niet. Configuratie van de dialer-lijst zoals in het volgende voorbeeld:
dialer-list X protocol ip permit
Opmerking: De waarde voor X moet gelijk zijn aan die gebruikt wordt met de opdracht dialer-groep onder het dialoogvenster.
Voorbeeld 4
*Mar 1 00:25:32.551: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) *Mar 1 00:25:32.555: Di1 DDR: No free dialer - starting fast idle timer.
In dit geval moet het uitgaande pakket als interessant genoeg worden beschouwd om de link op te halen, maar er is geen fysieke interface beschikbaar om de oproep te plaatsen. Zorg ervoor dat dialer pool-lid X is geconfigureerd in de fysieke interface en dialer pool X wordt geconfigureerd in de snelkiezerinterface. Voorbeeld:
interface BRI0 dialer pool-member 1 ! interface Dialer1 dialer pool 1
Controleer ook dat de BRI interface niet in sluitingsstaat is.
Voorbeeld 5
*Mar 1 00:37:24.235: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) *Mar 1 00:37:24.239: Di1 DDR: Cannot place call, no dialer string set.
In dit geval wordt er geen dialer string ingesteld in de dialer interface. De router wil een vraag plaatsen maar weet niet het ISDN-indexnummer om te bellen. Defineert een dialer-string:
interface Dialer1 dialer string 8134
Raadpleeg voor meer informatie over probleemoplossing het gedeelte "De bellenrouter stuurt geen SETUP-bericht" in het document Problemen oplossen door ISDN BRI Layer 3 te gebruiken voor het foutherstel van de ISDN Q931-opdracht.
Terug naar het stroomschema voor de probleemoplossing
Probleemoplossing: Wordt de ISDN-gespreksverbinding succesvol verbonden?
Om te bepalen of de ISDN-aanroep verbonden is, zoek dan een CONNECT_ACK- en %LINK-3-UPDOWN-bericht in de versies:
*Mar 1 00:06:36.743: ISDN BR0: TX -> CONNECT_ACK pd = 8 callref = 0x02 *Mar 1 00:06:36.751: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
Als u dit bericht ziet, is uw ISDN-oproep goed aangesloten en kunt u naar de volgende stap gaan. Als u een dergelijk bericht niet ziet, raadpleeg dan hieronder voor de mogelijke oorzaken.
Terug naar het stroomschema voor de probleemoplossing
Symptoom: De ISDN-oproep sluit geen succesvolle verbinding aan
- Als u uitvoer ziet die vergelijkbaar is met de volgende, controleer of de ISDN-kabel is aangesloten op zowel de router als de Telco-ingang.
*Mar 1 21:31:18.190: Di1 DDR: ip (s=x1.x2.x3.x4, d=y1.y2.y3.y4), 100 bytes, outgoing interesting (ip PERMIT) *Mar 1 21:31:18.190: BR0 DDR: rotor dialout [priority] *Mar 1 21:31:18.198: BR0 DDR: Dialing cause ip (s=x1.x2.x3.x4, d=y1.y2.y3.y4) *Mar 1 21:31:18.198: BR0 DDR: Attempting to dial 8134. *Mar 1 21:31:20.186: Di1 DDR: ip (s=x1.x2.x3.x4, d=y1.y2.y3.y4), 100 bytes, outgoing interesting (ip PERMIT). *Mar 1 21:31:26.226: ISDN BR0: Could not bring up interface *Mar 1 21:31:26.226: BRI0: wait for isdn carrier timeout, call id=0x849E *Mar 1 21:31:26.246: ISDN BR0: Could not bring up interface. Success rate is 0 percent (0/5)
- Controleer of het ISDN-circuit goed werkt. Gebruik de opdracht ISDN status tonen om te verifiëren dat Layer 1 actief is, Layer 2 is MULTIPLE_FRAME_ESTABLISHED en de SPIDs (indien nodig) geldig zijn. Raadpleeg voor meer informatie het document Gebruik van de ISDN-statusopdracht voor BRI-probleemoplossing.
Als u de uitvoer van een opdracht ISDN-status van uw Cisco-apparaat hebt, kunt u Cisco CLI Analyzer gebruiken om potentiële problemen en oplossingen weer te geven. Om Cisco CLI Analyzer te gebruiken, moet u een geregistreerde gebruiker zijn, inloggen en JavaScript ingeschakeld hebben. - Controleer dat de geconfigureerde ISDN-dialerstring correct is. Houd in gedachten dat u een vooraanstaande nul, negen of andere cijfers kunt moeten toevoegen om een buitenlijn te krijgen wanneer u door een PBX-systeem wordt aangesloten.
- Als de verbinding gebruik maakt van een langeafstandsbediening, neemt u contact op met uw plaatselijke telco en de langeafstandsaanbieder om te controleren of de service is geactiveerd. Vaak heeft de lokale Telco het ISDN circuit verkeerd ingesteld zodat de uitgaande ISDN-oproepen op lange afstand niet worden overgeschakeld op het juiste lange-afstand provider-netwerk. U dient ook te controleren of het langeafstandsdienstennetwerk functioneert.
In de V.S. en in situaties waar Telco of langeafstandsprovider het probleem niet kan oplossen, kunt u een PreSubscribed Interexchange Carrier (PIC) gebruiken. PIC-codes zijn zeven-cijferig prefixes die de Amerikaanse langeafstandsvervoerders naar de lokale uitwisselingsvervoerders (LEC) identificeren. Dit stelt klanten in staat om verschillende langeafstandsvervoerders te gebruiken voor individuele gesprekken. De PIC-code wordt ingesteld als voorvoegsel bij het geselecteerde nummer. De meeste PIC’s hebben het formaat 1010xxx.
Gebruik geen dialer string xxxxx of geen dialer map om het bestaande nummer te verwijderen en dan het nieuwe nummer te configureren.
Bijvoorbeeld, dialer string 1010321512551111.
- Zoek een ISDN-verbindingsbericht.
De software van Cisco IOS® decodeert de oorzaakcode in dit ontkoppelde bericht en geeft u een duidelijk tekstbericht dat vaak nuttige informatie bevat die tot de oorzaak van het probleem leidt. Mogelijke koorden die u hier kunt vinden zijn:
- Niet-toegewezen of niet-toegewezen nummer
- Oncompatibele bestemming (die beide aangeven dat het gedialineerde nummer niet correct is)
- Aantal bezig (dat aangeeft dat de opgeroepen kant druk is)
- Tijdelijke storing (hetgeen wijst op een tijdelijke storing op het Telco-netwerk)
Om de mogelijke oorzaak te vinden voor een specifieke ontkoppelde oorzaak, raadpleegt u het begrip van debug ISDN Q931 Oorzaak van verbroken verbinding.
Een verbroken verbinding door een incorrect ISDN-nummer kan bijvoorbeeld worden aangegeven met:
*Mar 3 00:10:38.756: ISDN BR0: RX <- DISCONNECT pd = 8 callref = 0xEB *Mar 3 00:10:38.764: Cause i = 0x84D8 - Incompatible destination
Verwijs naar het document dat de oorzaakcodes uit de verbinding verbreken heeft, kunnen we bepalen dat de code uit de verbinding is gehaald door een poging om aan te sluiten op een niet-ISDN-apparaat (bijvoorbeeld een analoge lijn).
Een verbroken verbinding door een niet juist geformatteerd nummer kan worden aangegeven met:
Aug 13 18:23:14.734: ISDN BR0: RX <- RELEASE_COMP pd = 8 callref = 0x86
Aug 13 18:23:14.742: Cause i = 0x829C - Invalid number format (incomplete number)Verwijzing naar het document Understanding debug ISDN Q931 Disconnect Cause Codes, dan kunnen we bepalen dat de verbroken code werd veroorzaakt door een ongeldig formaat voor het externe ISDN-nummer. De verbinding faalt omdat het doeladres in een niet herkenbare indeling (aan de schakelaar) wordt aangeboden of het doeladres onvolledig is.
Het volgende voorbeeld toont een verworpen vraag wegens een incorrect aantal ISDN:
*Mar 13 11:29:04.758: ISDN BR0: RX <- RELEASE_COMP pd = 8 callref = 0x83 *Mar 13 11:29:04.769: Cause i = 0x8295 - Call rejected
- Als uw Telco u van de het dienstprofiel identificatoren (SPIDs) heeft voorzien om te worden gebruikt, zorg er dan voor dat deze SPIDs op de BRI interface zijn geconfigureerd. SPID's worden gewoonlijk alleen in de VS en met NI- en DMS-switches gebruikt (5ess-switches hebben geen SPID's nodig).
interface BRI0 isdn spid1 51255511110101 5551111 isdn spid2 51255511120101 5551112
U kunt de opdracht ISDN-status tonen gebruiken om te controleren of de SPID's juist zijn.
Raadpleeg voor meer informatie de ISDN BRI SPID’s voor probleemoplossing van het document.
Als u de uitvoer van een opdracht ISDN-status van uw Cisco-apparaat hebt, kunt u Cisco CLI Analyzer gebruiken om potentiële problemen en oplossingen weer te geven. Om Cisco CLI Analyzer te gebruiken, moet u een geregistreerde gebruiker zijn, inloggen en JavaScript ingeschakeld hebben. - Als de bovenstaande procedure het probleem niet heeft opgelost, gebruikt u het document Problemen oplossen door ISDN BRI Layer 3 te gebruiken voor het verder oplossen van problemen met ISDN BRI Layer 3.
Terug naar het stroomschema voor de probleemoplossing
Probleemoplossing: Is de PPP LCP-fase geslaagd?
In de debug-uitvoer ziet u een berichtregel naar:
*Mar 1 00:06:36.887: BR0:1 LCP: State is Open
Als u deze regel ziet, betekent dit dat er met succes is onderhandeld over Link Control Protocol (LCP). Elke andere dan geopende toestand geeft aan dat LCP is mislukt.
Terug naar het stroomschema voor de probleemoplossing
Symptoom: PPP LCP-fase is niet geslaagd
Mogelijke oorzaak: PPP wordt niet geconfigureerd
Als u output gelijkend op de volgende lijnen hebt debug, betekent dit dat PPP niet is gestart.
*Mar 2 19:34:21.761: Di1 DDR: dialer protocol up. *Mar 2 19:34:23.397: Di1 DDR: ip (s=10.48.74.9, d=10.0.0.14), 100 bytes, outgoing interesting (ip PERMIT). *Mar 2 19:34:25.397: Di1 DDR: ip (s=10.48.74.9, d=10.0.0.14), 100 bytes, outgoing interesting (ip PERMIT). *Mar 2 19:34:27.397: Di1 DDR: ip (s=10.48.74.9, d=10.0.0.14), 100 bytes, outgoing interesting (ip PERMIT) *Mar 2 19:34:27.753: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 8101.
! -- Call connects but the router does not send any PPP CONFREQ packets *Mar 2 19:34:29.397: Di1 DDR: ip (s=10.48.74.9, d=10.0.0.14), 100 bytes, outgoing interesting (ip PERMIT). Success rate is 0 percent (0/5)
Let op van de debug uitvoer dat de router geen PPP CONFREQ-berichten verzenden. Dit is waarschijnlijk omdat de interface niet voor PPP insluiting is geconfigureerd.
In dit geval, controleer of u de opdracht van de insluitingspp onder de dialerinterface en de fysieke interface hebt ingesteld. Hieronder volgen enkele voorbeelden:
interface Dialer1 encapsulation ppp or
interface BRI 0
encapsulation ppp
Mogelijke oorzaak: ISDN-snelheidswanverhouding
Soms ziet u alleen uitgaande LCP CONFREQ-berichten, maar geen inkomende LCP-berichten. Hieronder wordt een voorbeeld gegeven:
*Mar 14 01:49:10.160: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up ! -- Call is connected. PPP negotiation will begin
*Mar 14 01:49:10.168: %DIALER-6-BIND: Interface BR0:1 bound to profile Di1.
*Mar 14 01:49:10.188: BR0:1 PPP: Treating connection as a callout
*Mar 14 01:49:10.188: BR0:1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 0 load] ! -- PPP negotiation begins
*Mar 14 01:49:10.196: BR0:1 LCP: O CONFREQ [Closed] id 24 len 15
*Mar 14 01:49:10.200: BR0:1 LCP: AuthProto CHAP (0x0305C22305)
*Mar 14 01:49:10.204: BR0:1 LCP: MagicNumber 0x545D708A (0x0506545D708A). ! -- Outgoing Configure-Request (CONFREQ)
*Mar 14 01:49:12.176: BR0:1 LCP: TIMEout: State REQsent ! -- Router has not received a CONFREQ from the peer, hence the timeout
*Mar 14 01:49:12.180: BR0:1 LCP: O CONFREQ [REQsent] id 25 len 15
*Mar 14 01:49:12.184: BR0:1 LCP: AuthProto CHAP (0x0305C22305)
*Mar 14 01:49:12.188: BR0:1 LCP: MagicNumber 0x545D708A (0x0506545D708A).
*Mar 14 01:49:14.160: BR0:1 LCP: TIMEout: State REQsent
*Mar 14 01:49:14.164: BR0:1 LCP: O CONFREQ [REQsent] id 26 len 15
*Mar 14 01:49:14.168: BR0:1 LCP: AuthProto CHAP (0x0305C22305)
*Mar 14 01:49:14.172: BR0:1 LCP: MagicNumber 0x545D708A (0x0506545D708A)
Dit probleem kan worden veroorzaakt door:
- Het externe gedeelte wordt niet voor PPP geconfigureerd. Configureer de opdracht insluitingstoets op het afstandsbediening
- Pakketten komen niet door de transmissiemedia. De meest voorkomende oorzaak van dit probleem is een ISDN-snelheidsfout
De aard van het probleem, vanuit een ISDN-standpunt, is dat de ene kant waarschijnlijk een verbinding maakt op 56k terwijl de andere kant een verbinding maakt op 64k. Het is mogelijk dat het lokale circuit of de afstandsbediening de standaard 64K-aansluitingen niet ondersteunt. Probeer beide eindpunten te configureren op 56k.
Voor snelkiezerprofielen:
maui-soho-01(config)#interface Dialer1 maui-soho-01(config-if)#dialer string 81560 class 56k
! -- Dial 81560 and use the map-class named "56k" (defined below) maui-soho-01(config-if)#exit maui-soho-01(config)#map-class dialer 56k
! -- map-class named "56k" that was used with the dialer string
! -- in int Dialer1
maui-soho-01(config-map-clas)#dialer isdn speed 56
! -- Set the speed of the call to be 56k (default is 64k)
Voor verouderde DDR (dialerkaarten):
maui-soho-01(config)#interface bri 0 maui-soho-01(config-if)#dialer map ip 10.1.1.1 name maui-nas-08 speed 56 81560
!-- The keyword speed 56 sets the outgoing call rate at 56k
Mogelijke oorzaak: De twee routers zijn het niet eens over een verificatie-protocol (CHAP of PAP) dat moet worden gebruikt
Als u bug-uitvoer hebt ingesteld die vergelijkbaar is met de volgende lijnen, dan duidt dit erop dat de router en de afgelegen kant niet akkoord zijn gegaan met een te gebruiken verificatieprotocol:
*Mar 1 00:07:24.051: BR0:1 LCP: I CONFREQ [ACKrcvd] id 136 len 14 *Mar 1 00:07:24.055: BR0:1 LCP: AuthProto PAP (0x0304C023) *Mar 1 00:07:24.059: BR0:1 LCP: MagicNumber 0x1110C3C5 (0x05061110C3C5) ! -- An incoming CONFREQ (Config-Request) indicating the peer is
! -- willing to do PAP *Mar 1 00:07:24.063: BR0:1 LCP: O CONFNAK [ACKrcvd] id 136 len 9 *Mar 1 00:07:24.063: BR0:1 LCP: AuthProto CHAP (0x0305C22305) ! -- The router send a Configure-Negative-Acknowledge (CONFNAK) rejecting PAP
! -- The router suggests CHAP instead *Mar 1 00:07:24.087: BR0:1 LCP: I CONFREQ [ACKrcvd] id 137 len 14 *Mar 1 00:07:24.091: BR0:1 LCP: AuthProto PAP (0x0304C023) *Mar 1 00:07:24.091: BR0:1 LCP: MagicNumber 0x1110C3C5 (0x05061110C3C5) ! -- The peer once again requests PAP
! -- This is probably because PAP is the only protocol configured on the peer
! -- The router will once again CONFNAK PAP and suggest CHAP *Mar 1 00:07:24.095: BR0:1 LCP: O CONFNAK [ACKrcvd] id 137 len 9 *Mar 1 00:07:24.099: BR0:1 LCP: AuthProto CHAP (0x0305C22305) ! -- The router NAKs PAP and suggests CHAP for the 2nd time *Mar 1 00:07:24.119: BR0:1 LCP: I TERMREQ [ACKrcvd] id 138 len 4 *Mar 1 00:07:24.123: BR0:1 LCP: O TERMACK [ACKrcvd] id 138 len 4 ! -- The two routers cannot agree on LCP parameters so the call is disconnected
Controleer in dit geval of u het volgende hebt ingesteld:
interface Dialer1 encapsulation ppp ppp authentication chap pap callin ! -- This permits both CHAP and PAP and one-way authentication
Raadpleeg de volgende documenten voor meer informatie over Challenge Handshake Authentication Protocol (CHAP) of Wachtwoordverificatie Protocol (PAP):
- Het begrijpen en configureren van PPP CHAP-verificatie
- PPP-verificatie met de ppp chap hostname en ppp-verificatie-ketting die opdrachten oproept
- Configuratie- en probleemoplossing van PPP Password-verificatie Protocol (PAP)
U kunt de Cisco Support Community ook gebruiken voor verdere PPP-probleemoplossing.
Terug naar het stroomschema voor de probleemoplossing
Probleemoplossing: Is PPP-verificatie geslaagd?
Controleer de debug uitvoer voor een regel die hier op lijkt:
*Mar 1 00:06:36.943: BR0:1 PPP: Phase is UP
Terug naar het stroomschema voor de probleemoplossing
Symptoom: PPP-verificatie heeft geen succes
Zorg ervoor dat u de volgende regels hebt ingesteld:
interface Dialer1 ppp chap hostname XXXXX ppp chap password YYYYY ppp pap sent-username XXXXX password YYYYY
In het voorbeeld is XXXXX uw gebruikersnaam en YYYY uw wachtwoord.
Opmerking: Configureer alleen de gebruikersnaam en het wachtwoord voor de verificatiemethode die u en de peer gebruiken. Bijvoorbeeld, als u beiden geen PAP zult gebruiken, dan hebt u niet de Pp pap verstuurde-gebruikersnaam opdracht nodig. Als u echter niet zeker weet of de peer support PAP of CHAP, moet u beide configureren.
Afhankelijk van uw IOS van Cisco softwareversie en -configuratie, kan het wachtwoord versleuteld worden in uw configuratie. Als dit het geval is, ziet u bij het opdracht voor het tonen van de configuratie het woord "wachtwoord" gevolgd door cijfer 7 en dan een reeks getallen, zoals in het volgende voorbeeld:
interface Dialer1 ppp chap password 7 140005
In dit geval kunt u niet controleren of het ingestelde wachtwoord juist is of niet door de configuratie te bekijken. Om er zeker van te zijn dat het wachtwoord juist is, dient u de configuratie-modus in te voeren en het wachtwoord vervolgens weer te verwijderen en te configureren. Om een wachtwoordstoring in het debug-venster te identificeren, vergelijk uw debug-uitvoer met de onderstaande voorbeelduitvoer.
Als deze router de peer voor authentiek zal verklaren, dan zal u zeker zijn om de opdracht gebruikersnaam voor de gebruikersnaam wachtwoord voor de gebruikersnaam te configureren, waar de gebruikersnaam de naam is die door de peer router voor verificatie is opgegeven.
Voorbeeld 1
Een bericht zoals het bericht hieronder betekent dat het wachtwoord van het CHAP niet geldig is.
*Mar 1 00:16:54.403: BR0:1 CHAP: I CHALLENGE id 94 len 24 from "ISP" ! -- Incoming CHAP challenge *Mar 1 00:16:54.407: BR0:1 CHAP: Using alternate hostname XXXXX ! -- Using alternate hostname configured with ppp chap hostname command *Mar 1 00:16:54.411: BR0:1 CHAP: Username ISP not found *Mar 1 00:16:54.415: BR0:1 CHAP: Using default password ! -- Using password configured with ppp chap password command *Mar 1 00:16:54.415: BR0:1 CHAP: O RESPONSE id 94 len 26 from "XXXXX" ! -- Sending response from "XXXXX" which is the alternate hostname for the router *Mar 1 00:16:54.439: BR0:1 CHAP: I FAILURE id 94 len 25 msg is "MD/DES compare failed" ! -- Incoming CHAP failure. The remote router failed to authenticate this router. ! -- Check the username and password configured on both routers *Mar 1 00:16:54.447: BR0:1 LCP: I TERMREQ [Open] id 165 len 4 *Mar 1 00:16:54.451: BR0:1 LCP: O TERMACK [Open] id 165 len 4
Tip: Een inkomende mislukking van CHAP (aangegeven door CHAP: I FAILURE) betekent dat de peer de router niet echt kon verklaren. Gebruik debug ppp onderhandeling op de peer router om de nauwkeurige oorzaak van de mislukking te bepalen.
Raadpleeg voor meer informatie de document PPP-verificatie met behulp van de ppp chap-hostname en ppp-verificatieschap waarin Opdrachten worden opgeroepen.
Voorbeeld 2
Een bericht zoals het bericht hieronder kan betekenen dat de gebruikersnaam voor CHAP niet geldig is:
*Mar 1 00:18:34.831: BR0:1 CHAP: I CHALLENGE id 97 len 24 from "ISP" ! -- Incoming CHAP challenge *Mar 1 00:18:34.835: BR0:1 CHAP: Using alternate hostname Xdwqdqw ! -- Using alternate hostname configured with ppp chap hostname command *Mar 1 00:18:34.839: BR0:1 CHAP: Username ISP not found *Mar 1 00:18:34.839: BR0:1 CHAP: Using default password ! -- Using password configured with ppp chap password command *Mar 1 00:18:34.843: BR0:1 CHAP: O RESPONSE id 97 len 28 from "Xdwqdqw" ! -- Sending response from "Xdwqdqw" which is the alternate hostname
! -- for the router *Mar 1 00:18:34.867: BR0:1 CHAP: I FAILURE id 97 len 26 msg is "Authentication failure" ! -- Incoming CHAP failure. The remote router failed to authenticate
! -- this router. Check the username and password configured on both routers *Mar 1 00:18:34.875: BR0:1 LCP: I TERMREQ [Open] id 171 len 4 *Mar 1 00:18:34.879: BR0:1 LCP: O TERMACK [Open] id 171 len 4
Tip: Een inkomende mislukking van CHAP (aangegeven door CHAP: I FAILURE) betekent dat de peer de router niet echt kon verklaren. Gebruik debug ppp onderhandeling op de peer router om de nauwkeurige oorzaak van de mislukking te bepalen.
Raadpleeg voor meer informatie de document-PPP-verificatie met de ppp-naam en de ppp-verificatieschap waarin opdrachten worden opgeroepen.
Voorbeeld 3
Een bericht als hieronder betekent dat het PAP-wachtwoord niet geldig is:
*Mar 1 00:21:33.927: BR0:1 PAP: O AUTH-REQ id 3 len 18 from "XXXXX" ! -- Outgoing PAP Authentication Request from XXXXX
! -- XXXXX is the username configured in
! -- ppp pap sent-username XXXXX password YYYYY *Mar 1 00:21:33.947: BR0:1 PAP: I AUTH-NAK id 3 len 27 msg is "Authentication failure" ! -- An incoming PAP failure. The peer could not authenticate this router
! -- Verify that the username and password configured on both routers
! -- are identical *Mar 1 00:21:33.955: BR0:1 LCP: I TERMREQ [Open] id 182 len 4 *Mar 1 00:21:33.955: BR0:1 LCP: O TERMACK [Open] id 182 len 4 *Mar 1 00:21:33.959: BR0:1 PPP: Phase is TERMINATING
Raadpleeg voor meer informatie het PAP-protocol (Wachtwoord voor configuratie en probleemoplossing) van het document.
Voorbeeld 4
Een bericht als hieronder betekent dat de PAP-gebruikersnaam niet geldig is:
*Mar 1 00:20:41.023: BR0:1 PPP: Phase is AUTHENTICATING, by the peer *Mar 1 00:20:41.031: BR0:1 PAP: O AUTH-REQ id 1 len 17 from "ewddew" ! -- Outgoing PAP Authentication Request from ewddew
! -- ewddew is the username configured in
! -- ppp pap sent-username ewddew password YYYYY *Mar 1 00:20:41.047: BR0:1 PAP: I AUTH-NAK id 1 len 27 msg is "Authentication failure" ! -- An incoming PAP failure. The remote router could not authenticate
! -- this router. Check the username and password configured on both routers
! -- Note the PAP authentication failure in example 3 and 4 are identical.
! -- Hence the only way to determine if the username, password or both are
! -- wrong is to run debug ppp negotiation on the authenticating router *Mar 1 00:20:41.055: BR0:1 LCP: I TERMREQ [Open] id 178 len 4 *Mar 1 00:20:41.059: BR0:1 LCP: O TERMACK [Open] id 178 len 4 *Mar 1 00:20:41.063: BR0:1 PPP: Phase is TERMINATING
Raadpleeg voor meer informatie het PAP-protocol (Wachtwoord voor configuratie en probleemoplossing) van het document.
U kunt de Cisco Support Community ook gebruiken voor verdere PPP-probleemoplossing.
Terug naar het stroomschema voor de probleemoplossing
Probleemoplossing: Is de PPP NCP (IPCP)-fase voltooid?
Het belangrijkste element dat in IPCP is onderhandeld is het adres van elk peer. Vóór de IPCP-onderhandelingen, is elk peer in één van twee mogelijke staten; of het heeft een IP-adres of het heeft geen IP-adres. Als de peer al een adres heeft, stuurt het dat adres in een CONFREQ naar de andere peer. Als het adres acceptabel is voor de andere peer, wordt CONFACK teruggegeven. Als het adres niet acceptabel is, is het antwoord een CONFNAK met een adres voor de peer om te gebruiken.
Dit is de enige fase die niet goed kan worden geïdentificeerd door slechts één lijn te bekijken. Om er zeker van te zijn dat IP Control Protocol (IPCP) correct wordt weergegeven, moet u controleren of IP-adressen in beide richtingen zijn overeengekomen. Bekijk uw debug voor de volgende lijnen:
*Mar 1 00:06:36.967: BR0:1 IPCP: O CONFACK [REQsent] id 26 len 10 *Mar 1 00:06:36.971: BR0:1 IPCP: Address 194.183.201.1(0x0306C2B7C901)
en
*Mar 1 00:06:37.011: BR0:1 IPCP: I CONFACK [ACKsent] id 4 len 10 *Mar 1 00:06:37.015: BR0:1 IPCP: Address 194.183.201.2 (0x0306C2B7C902)
en
*Mar 1 00:06:37.015: BR0:1 IPCP: State is Open
Deze drie lijnen mogen elkaar niet onmiddellijk volgen. Het is belangrijk dat u controleert of er een vertrekkende Configure kennis (O CONFACK) is die, naast andere opties, een adres eronder heeft.
Er moet ook een inkomende Bevestiging (I CONFACK) met een ander IP adres onder het adres zijn binnengekomen.
Tenslotte moet er een regel zijn die bepaalt dat de IPCP-status open is. Na dit, zou u beiden IP adressen direct van uw router moeten kunnen met succes kunnen pingelen.
Terug naar het stroomschema voor de probleemoplossing
Symptoom: IPCP-onderhandeling (PPP) is niet geslaagd
Probleem: IP-adresonderhandeling mislukt
Eén van de reden waarom IPCP zou kunnen falen is te wijten aan een fout in de IP-adresonderhandeling. Zo kan de NAS proberen een adres aan de client toe te wijzen terwijl de clientrouter een ander IP-adres heeft ingesteld of een ander gemeenschappelijk probleem is wanneer de klant een adres vraagt en de NAS geen adressen voor de client heeft.
Op de belrouter:
Als de geroepen router dynamisch een IP-adres aan de oproepende router toewijst, controleer of u het ip-adres van de opdracht dat in de dialerinterface is onderhandeld hebt.
Als NAS Provider/ISP u een statisch IP adres heeft gegeven, controleer of dit ip adres (en SUBNET masker) in de dialer interface met het commando ip adres adres sub_mask wordt ingesteld.
Op de opgeroepen router:
Verzeker interface die de verbinding controleert (bijvoorbeeld, in Kiezer x) heeft een IP-adres en wijst een adres toe aan de peer met behulp van de peer standaard IP-adresopdracht.
Opmerking: Als de clientrouter een IP-adres heeft dat is ingesteld, hoeft u geen adres toe te wijzen aan de hand van de opdracht IP-adres.
Raadpleeg voor meer informatie de technologie voor het samenstellen van documenten: Technieken voor probleemoplossing.
Probleem: De geroepen router faalt de binding van het kiesprofiel
Als de geauthentiseerde gebruikersnaam niet overeenkomt met de afstandsbediening, ingesteld onder de dialerinterface, dan zal de verbinding worden verbroken door de opgeroepen router. Het volgende is een voorbeeld debug dialer uitvoer voor zo een fout:
Op de belrouter:
Het volgende debug toont een ontkoppeling veroorzaakt door een slecht dialerprofiel dat bindend is voor de opgeroepen router;
*Mar 15 03:19:13.050: BR0:1 CHAP: O CHALLENGE id 32 len 33 from "maui-soho-03"
*Mar 15 03:19:13.094: BR0:1 CHAP: I CHALLENGE id 32 len 33 from "maui-soho-01"
*Mar 15 03:19:13.094: BR0:1 CHAP: O RESPONSE id 32 len 33 from "maui-soho-03"
*Mar 15 03:19:13.134: BR0:1 CHAP: I SUCCESS id 32 len 4 ! -- CHAP authentication is successful
*Mar 15 03:19:13.222: ISDN BR0: RX <- DISCONNECT pd = 8 callref = 0xA0
*Mar 15 03:19:13.226: Cause i = 0x8090 - Normal call clearing ! -- We have received (RX) a DISCONNECT from the peer
! -- We have to move troubleshooting to the called router
*Mar 15 03:19:13.238: ISDN BR0: TX -> RELEASE pd = 8 callref = 0x20
*Mar 15 03:19:13.242: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
*Mar 15 03:19:13.250: BR0 DDR: has total 2 call(s), dial_out 0, dial_in 0
*Mar 15 03:19:13.254: BR0:1 PPP: Phase is TERMINATING
*Mar 15 03:19:13.254: BR0:1 LCP: State is Closed
*Mar 15 03:19:13.254: BR0:1 PPP: Phase is DOWN
*Mar 15 03:19:13.254: BRI0:1 DDR: disconnecting call
Opmerking: De indicatoren van de geroepen kant helpen niet bij het oplossen van dit probleem behalve om aan te geven dat de peer de vraag ontkoppelde. Verplaats de probleemoplossing naar de opgeroepen router.
Op de opgeroepen router:
Het volgende debug toont een roep die door de bindingskwesties van het dialerprofiel faalt:
*Mar 15 03:54:09.804: BR0:1 CHAP: O SUCCESS id 33 len 4
*Mar 15 03:54:09.808: BR0:1 CHAP: Processing saved Challenge, id 33
*Mar 15 03:54:09.812: BR0:1 DDR: Authenticated host maui-soho-03 with no matching dialer profile ! -- a binding failure because the dialer remote-name
! -- does not match the authenticated username
*Mar 15 03:54:09.816: BR0:1 DDR: disconnecting call
*Mar 15 03:54:10.086: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
*Mar 15 03:54:10.093: BR0:1 PPP: Phase is TERMINATING [0 sess, 0 load]
Oplossing:
Configuratie van de opdracht het nummer van de dialer in de dialerinterface. Het poolnummer moet overeenkomen met het poolnummer dat op de fysieke interface is ingesteld.
Configureer de opdracht van de naam dialer in de interface van het dialer. De opgegeven naam moet exact overeenkomen met de gebruikersnaam die door de router op afstand voor verificatie is opgegeven. In dit voorbeeld is de geauthenticeerde gebruikersnaam maui-soho-03.
Voor meer informatie over het oplossen van problemen bij bindende kwesties kunt u verwijzen naar de Kiezerprofielen van het document en de probleemoplossing.
U kunt de Cisco Support Community ook gebruiken voor verdere PPP-probleemoplossing.
Terug naar het stroomschema voor de probleemoplossing
Problemen met na verbinding
Symptoom: Roep blokkeert voortijdig of oproept maakt de verbinding niet los
Als de verbinding onverwachts wordt verbroken of de verbinding nooit wordt verbroken, controleer dan de inactiviteitstimer van de dialer en de interessante verkeersdefinitie. U kunt de opdracht Dialoogpakket debug gebruiken om te zien of een bepaald pakket interessant is of niet. Bijvoorbeeld:
Apr 26 01:57:24.483: Di1 DDR: ip (s=192.168.1.1, d=224.0.0.5), 64 bytes, outgoing uninteresting (list 101) Apr 26 01:57:26.225: Di1 DDR: ip (s=192.168.1.1, d=10.1.1.1), 100 bytes, outgoing interesting (list 101)
In het bovenstaande voorbeeld, zijn OSPF-hellos niet-interessant per access-list 101, terwijl het tweede pakket interessant is per access-list 101.
- Stel het inactiviteitstimer van de dialer in de configuratie van de dialer-interface in. De standaardinstelling is 120 seconden, maar u kunt deze waarde verhogen of verlagen naar gelang uw behoeften.
- Verandert de interessante verkeersdefinitie (ingesteld met de opdracht dialer-list). Als de verbinding voortijdig wordt verbroken, kunt u het interessante verkeer losser definiëren. Als de verbinding nooit verbroken wordt, verander je interessante verkeersdefinitie dan restrictiever. Bijvoorbeeld, kunt u het routeren van protocolverkeer als oninteressant definiëren. Hier is een voorbeelden van interessante verkeersdefinities:
access-list 101 remark Interesting traffic for dialer-list 1 access-list 101 deny ospf any any
!--- mark OSPF as uninteresting
!--- This will prevent OSPF hellos from keeping the link up.
access-list 101 deny udp any any eq ntp ! -- Define ntp traffic as NOT interesting.
! -- This will prevent periodic ntp traffic from keeping
! -- the link up indefinitely.
access-list 101 permit ip any any
! -- All other IP traffic is interesting.
! -- Change this depending on your traffic needs.
dialer-list 1 protocol ip list 101 ! -- this interesting traffic is applied to the dialer
! -- interface using dialer-group 1Raadpleeg voor meer informatie de technologie voor het samenstellen van documenten: Overzichten en toelichtingen.
Symptoom: Keert de verbinding af en toe door de router
In bepaalde situaties, kunt u opmerken dat de router de verbinding periodiek wijzert, zelfs al is er geen duidelijk gebruikersverkeer dat de verbinding vereist om omhoog te zijn. Dit kan resulteren in hoge tolkosten waar de ISDN-service per minuut wordt aangerekend.
De meest algemene oorzaak is dat een proces dat periodiek verkeer (zoals een routeringsprotocol, ntp, nmp enz.) genereert onopzettelijk als interessant kan worden aangewezen. Problemen oplossen is een probleem in twee stappen:
- Identificeer het verkeer dat de verbinding veroorzaakt om te bellen.
- Wijs dat verkeer als oninteressant aan.
Identificeer het verkeer dat de verbinding met de bel veroorzaakt.
Om het verkeer te identificeren dat de link om te bellen veroorzaakt, moet u het dialerpakket activeren. Controleer de router terwijl de verbinding van ISDN is verminderd en let op wat periodiek interessant verkeer dat probeert om de verbinding op te halen.
Tip: Tenzij specifiek nodig, wijzen alle routingprotocollen die op de router zijn geconfigureerd aan als oninteressant.
Het volgende voorbeeld toont periodiek OSPF hellos die als interessant wordt gemarkeerd:
*Mar 15 00:25:58.865: Di1 DDR: ip (s=172.22.25.1, d=224.0.0.5), 64 bytes, outgoing interesting (ip PERMIT)
De enige manier om te identificeren dat het bovenstaande pakket een OSPF hallo is van het bestemmingsadres (d=224.0.0.5) dat voor OSPF is gedefinieerd. De volgende tabel toont de adressen die worden gebruikt voor bepaalde gemeenschappelijke routingprotocollen:
|
Routing Protocol
|
Doeladres voor periodiek onderzoek updates of keepalives |
|
RIPv1
|
255.255.255.255
|
|
RIPv2
|
224.0.0.9
|
|
EINDTIJD
|
224.0.0.10
|
|
OSPF
|
224.0.0.5
|
Het verkeer dat de router veroorzaakt om te bellen (routingprotocol of ander periodiek verkeer) moet worden gemarkeerd als oninteressant.
Het periodiek verkeer als oninteressant aanwijzen
Verandert de interessante verkeersdefinitie (ingesteld met de opdracht dialer-list). In dit voorbeeld, definieer OSPF en NTP verkeer als oninteressant. Hier is een voorbeelden van interessante verkeersdefinities:
access-list 101 remark Interesting traffic for dialer-list 1 access-list 101 deny ospf any any
!--- mark OSPF as uninteresting
!--- This will prevent OSPF hellos from keeping the link up.
access-list 101 deny udp any any eq ntp ! -- Define ntp traffic as NOT interesting.
! -- This will prevent periodic ntp traffic from keeping
! -- the link up indefinitely.
access-list 101 permit ip any any
! -- All other IP traffic is interesting.
! -- Change this depending on your traffic needs.
dialer-list 1 protocol ip list 101 ! -- this interesting traffic is applied to the dialer interface
! -- using dialer-group 1
Raadpleeg voor meer informatie de technologie voor het samenstellen van documenten: Overzichten en toelichtingen.
Opmerking: OSPF heeft een functie die vraagcircuit wordt genoemd en kan ook hier worden gebruikt. Raadpleeg het document Waarom OSPF-On-Circuit-toetsen de link voor meer informatie opbergen
Symptoom: Tweede B-kanaal sluit geen verbinding aan
In veel gevallen kan de router slechts op één B-kanaal verbinden, terwijl het andere B-kanaal leeg blijft. Voor meer informatie over het oplossen van dit probleem raadpleegt u het document Problemen oplossen bij Tweede B-kanaals Call Fouten bij ISDN BRI Links.
IP-connectiviteitsproblemen
Als de ISDN-link naar voren komt maar u kunt geen verkeer via de link doorgeven, dan is het probleem waarschijnlijk een routing of NAT-gerelateerd probleem. Raadpleeg de Cisco-ondersteuningscommunity voor meer informatie over probleemoplossing.
Als u de ISDN-link als back-up van een WAN-verbinding gebruikt, raadpleegt u vervolgens de back-up van document Configuration en Troubleshooter DDR.
Gerelateerde informatie
FeedbackContact Cisco
- Een ondersteuningscase openen
- (Vereist een Cisco-servicecontract)