Er zijn veel redenen waarom de DSL-verbinding (Digital Subscriber Line) mogelijk niet goed werkt. Het doel van dit document is de oorzaak van de mislukking te isoleren en te repareren. De eerste stap voor het oplossen van problemen is om te bepalen welke laag van de ADSL-service (Asynchronous Digital Subscriber Line) niet werkt. Er zijn drie lagen waarin de fout kan voorkomen.
Layer 1 - DSL fysieke connectiviteit op de Digital Subscriber Line Access Multiplexer (DSLAM) van uw ISP
Layer 2.1 - ATM-connectiviteit
Layer 2.2 - Point-to-Point Protocol over ATM (PPPoA), Point-to-Point Protocol over Ethernet (PPPoE), RFC1483-overbrugging of RFC1483-routing
Layer 3 - IP
De makkelijkste manier om te bepalen welke laag u zou moeten beginnen problematisch te worden is de opdracht uit te geven ip interface korte te tonen. De uitvoer van deze opdracht verschilt enigszins afhankelijk van de configuratie.
827-ESC#show ip interface brief Interface IP-Address OK? Method Status Protocol ATM0 unassigned YES manual up up ATM0.1 unassigned YES unset up up Ethernet0 10.10.10.1 YES manual up up
Als de status van ATM0 en ATM0.1 omhoog is en het protocol omhoog is, begin met het oplossen bij Layer 2.
Als de ATM interfaces omlaag zijn of als ze naar boven blijven komen en vervolgens omlaag gaan (ze blijven niet omhoog en omhoog), beginnen met het oplossen van problemen op Layer 1.
Er zijn geen specifieke vereisten van toepassing op dit document.
Dit document is niet beperkt tot specifieke software- en hardware-versies.
Als het CD-lampje is ingeschakeld, gaat u naar het gedeelte Layer 2 Problemen van dit document.
Als het CD-licht uit is, gaat u door met de volgende vraag.
Controleer deze informatie bij uw ISP.
Als de DSL-poort niet op de DSL-wandingang is aangesloten, sluit u de poort op de muur aan met een 4-pins of 6-pins RJ-11 kabel. Dit is een standaard telefoonkabel.
Om te bepalen of de interface van ATM0 administratief weg is, geeft u deze opdracht in machtigingsmodus op de router uit:
Router#show interface atm 0 ATM0 is administratively down, line protocol is down <... snipped ...>
Als de ATM0 interfacestatus administratief is neergezet, geeft u de opdracht no shutdown uit onder de ATM0-interface.
Router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router(config)#interface atm 0 Router(config-if)#no shut Router(config-if)#end Router#write memory
Als de ATM0 interfacestatus beneden is, ziet de router geen drager op de ADSL-lijn. Dit duidt in het algemeen op een van twee punten:
De actieve pennen op de DSL wandingang zijn onjuist.
Uw ISP heeft geen DSL-service op deze wandingang ingesteld.
Cisco DSL Router xDSL-poortadapters
De RJ-11-connector biedt een xDSL-verbinding naar externe media via een standaard RJ-11 6-pins modulaire ingang.
insteken | Beschrijving |
---|---|
3 | XDSL_Tip |
4 | XDSL_Ring |
Om te bepalen als de interface van ATM0 laag en laag is, geeft u de opdracht interface-ATM 0 van de modus van de router uit:
Router#show interface atm 0 ATM0 is down, line protocol is down <... snipped ...>
Als de ATM-interface op en neer is—en niet administratief omlaag—controleer de pinout van uw DSL-wandingang. De DSL-router gebruikt een standaard RJ-11 (4-pins of 6-pins) kabel om de ADSL-verbinding naar de wandingang te maken. Het middelste paar spelden op de RJ-11-kabel wordt gebruikt om het ADSL-signaal (pennen 3 en 4 op een 6-pins kabel of pennen 2 en 3 op een 4-pins kabel) aan te voeren.
Als u zeker bent dat u de juiste spelden op de wandingang hebt en de ATM0-interface nog steeds op en neer is, vervangt u de RJ-11-kabel tussen de DSL-poort en uw wandingang. Als de interface nog steeds plat is nadat u de RJ-11-kabel hebt vervangen, neemt u contact op met uw ISP en heeft u de ISP ingeschakeld om te controleren of DSL-service is ingeschakeld op de wandingang die u gebruikt.
Als u niet zeker weet welke spelden op de wandingang actief zijn, kunt u dit navragen bij uw ISP.
Als u hebt geverifieerd dat uw DSL-kabel goed is en dat u de juiste pinouts hebt, is de volgende stap om te zorgen dat u de juiste elektriciteitstoevoer voor de 827 hebt.
Opmerking: De 827 gebruikt niet dezelfde voeding als andere 800 Series routers.
Om te bepalen of u de juiste voedingseenheid hebt, wacht u aan de achterzijde van de voedingsadapter op uitgang +12V 0,1A, -12V 0,1A, +5V 3A, -24V 0,12A en -71V 0,12A. Als uw stroomtoevoer niet voldoet aan de velden +12V en -12V, is het voor een andere Cisco 800 Series router en werkt niet aan de 827-router. Merk op dat als u de verkeerde voedingseenheid gebruikt, Cisco 827-machten omhoog draait, maar niet in staat is om (verbinding maken) naar de ISP DSLAM te trainen.
Als alles tot dit punt in de procedure voor het oplossen van problemen op Layer 1 correct is, is de volgende stap om te verzekeren u de juiste DSL in werking hebt. Cisco raadt het gebruik van dsl in de bedrijfsmodus auto aan als u niet zeker weet welke DMT-technologie uw ISP gebruikt. Dit zijn de opdrachten om de automatische detectie van de besturingsmodus te configureren:
Router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router(config)#interface atm 0 Router(config-if)#dsl operating-mode auto Router(config-if)#end Router#write memory
Verkrijg deze informatie van uw ISP of telefoonbedrijf.
Met een PPPoE-implementatie is er geen makkelijke manier om dynamisch uw Permanent Virtual Circuit (PVC)-waarden (VPN/VCI) van een virtueel pad-identificator/virtueel kanaal-id te ontdekken. Neem contact op met uw ISP als u niet zeker weet van uw PVC-waarden.
Als u de correcte waarden van PVC hebt, is de volgende stap om te verifiëren dat u PPP met uw ISP probeert te onderhandelen. Hiervoor geeft u de opdracht de interface ATM0 uit en controleert u de invoer- en uitvoerpakketten.
Router#show interface atm0 ATM0 is up, line protocol is up Hardware is DSLSAR (with Alcatel ADSL Module) MTU 4470 bytes, sub MTU 4470, BW 128 Kbit, DLY 16000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ATM, loopback not set Encapsulation(s): AAL5, PVC mode 24 maximum active VCs, 256 VCS per VP, 1 current VCCs VC idle disconnect time: 300 seconds Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters never Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 5 bits/sec, 0 packets/sec 5 minute output rate 7 bits/sec, 0 packets/sec 100 packets input, 5600 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 250 packets output, 1400 bytes, 0 underruns 0 output errors, 0 collisions, 2 interface resets 0 output buffer failures, 0 output buffers swapped out
Als de tellers van het invoerpakket aan het verhogen zijn, zou u PPPoE onderhandelingspakketten van uw ISP moeten ontvangen. Als dit niet het geval is, kunt u uw ISP bellen.
Als de uitvoer gebonden tellers aan het verhogen zijn, zou u PPPoE onderhandelingspakketten moeten verzenden. Als dit niet het geval is, controleer de configuratie op de router. Als PPP goed wordt geconfigureerd, worden de PPP-onderhandelingspakketten voortdurend naar de ATM0-interface verzonden.
Als pakketten alleen in de uitgaande richting toenemen, gaat u verder met de stappen voor het oplossen van problemen in dit document.
PPPoE wordt in twee fasen uitgevoerd. De eerste fase is de instelling van de PPPoE-sessie, en de tweede fase is de PPP-onderhandeling. PPPoE moet voorafgaand aan de onderhandeling over standaard PPP-parameters worden ingesteld. De makkelijkste manier om te bepalen als u een actieve PPPoE-sessie hebt is de show vpdn opdracht uit te geven.
Router#show vpdn %No active L2TP tunnels %No active L2F tunnels %No active PPTP tunnels PPPoE Tunnel and Session Information Total tunnels 1 sessions 1 PPPoE Tunnel Information Session count: 1 PPPoE Session Information SID RemMAC LocMAC Intf Vast OIntf VP/VC 0 0000.0000.0000 0000.0000.0000 UNKN ATM0 8/35
In dit voorbeeld zijn geen PPPoE sessies actief. Dit wordt aangegeven door een SID van 0 en de RemMAC en LocMAC van 000.000.000.000. Als u in deze staat bent, ga dan naar de volgende sectie.
Een PPPoE-sessie die met succes wordt onderhandeld ziet er als volgt uit:
Router#show vpdn %No active L2TP tunnels %No active L2F tunnels PPPoE Tunnel and Session Information Total tunnels 1 sessions 1 PPPoE Tunnel Information Session count: 1 PPPoE Session Information SID RemMAC LocMAC Intf Vast OIntf VP/VC 1 0050.7359.35b7 0001.96a4.84ac Vi1 UP ATM0 8/35
In dit voorbeeld kunt u zien dat de SID een niet-nul getal is en dat zowel de RemMAC- als LocMAC-velden ingevuld zijn. Het andere aandachtsgebied is de Vast, wat aangeeft of PPP met succes is onderhandeld en geauthentiseerd. Als de Vast UP is, is PPP met succes overeengekomen en geauthentiseerd, en u kunt verder gaan naar de Waarom kan ik sommige webpagina's met PPPoE toegang hebben maar anderen niet? gedeelte van dit document. Als de Vast is gevallen, gaat u verder met de volgende sectie.
Als u geen actieve PPPoE-sessie hebt ingesteld, moet u de opdracht debug vpdn ppo-gebeurtenissen uitgeven om te bepalen wat PPPoE niet doet.
Router#debug vpdn pppoe-events *Mar 3 21:49:38.030: Sending PADI: vc=8/35 *Mar 3 21:49:38.030: padi timer expired *Mar 3 21:50:10.030: Sending PADI: vc=8/35 *Mar 3 21:50:10.030: padi timer expired *Mar 3 21:50:42.030: Sending PADI: vc=8/35 *Mar 3 21:50:42.030: padi timer expired *Mar 3 21:51:14.030: Sending PADI: vc=8/35 *Mar 3 21:51:14.030: padi timer expired *Mar 3 21:51:46.030: Sending PADI: vc=8/35 *Mar 3 21:51:46.030: padi timer expired Router#undebug all
In dit voorbeeld, stuurt de router van Cisco DSL ononderbroken de kaders van de Initiatie van de Actieve Ontdekking PPPoE (PADI) naar de ISP zonder antwoord. Het PADI-kader is het eerste in een reeks PPPoE call-Setup frames. Als uw ISP niet reageert met een PADO-aanbod (PPPoE Active Discovery Offer), wordt de PPPoE-onderhandeling niet succesvol. De enige oplossing voor dit probleem is om contact op te nemen met uw ISP.
Als u met succes PPPoE onderhandelt, lijkt uw debug vpdn ppo-gebeurtenissen uitvoer als deze uitvoer:
Router#debug vpdn pppoe-events *Mar 3 21:49:38.030: Sending PADI: vc=8/35 *Mar 3 21:50:10.030: PPPOE: we've got our pado and the pado timer went off *Mar 3 21:50:35.030: OUT PADR from PPPoE tunnel *Mar 3 21:50:50.030: IN PADS from PPPoE tunnel Router#undebug all
Als PPPoE met succes wordt overeengekomen, ga verder met de volgende sectie over het oplossen van PPP.
Als Layer 1 boven is en u de juiste VPI/VCI hebt, is de volgende stap om ervoor te zorgen dat PPP correct verschijnt. Om dit te bereiken, moet u een reeks debug-opdrachten op de Cisco DSL-router uitvoeren en de uitvoer interpreteren. Het primaire debug die u gebruikt is debug ppp onderhandeling. Deze output van het bevel is een voorbeeld van een succesvolle PPP onderhandeling:
Router#debug ppp negotiation PPP protocol negotiation debugging is on Router# 2w3d: Vi1 PPP: No remote authentication for call-out 2w3d: Vi1 PPP: Phase is ESTABLISHING 2w3d: Vi1 LCP: O CONFREQ [Open] id 146 len 10 2w3d: Vi1 LCP: MagicNumber 0x8CCF0E1E (0x05068CCF0E1E) 2w3d: Vi1 LCP: O CONFACK [Open] id 102 Len 15 2w3d: Vi1 LCP: AuthProto CHAP (0x0305C22305) 2w3d: Vi1 LCP: MagicNumber 0xD945AD0A (0x0506D945AD0A) 2w3d: Di1 IPCP: Remove route to 20.20.2.1 2w3d: Vi1 LCP: I CONFACK [ACKsent] id 146 Len 10 2w3d: Vi1 LCP: MagicNumber 0x8CCF0E1E (0x05068CCF0E1E) 2w3d: Vi1 LCP: State is Open 2w3d: Vi1 PPP: Phase is AUTHENTICATING, by the peer 2w3d: Vi1 CHAP: I CHALLENGE id 79 Len 33 from "6400-2-NRP-2" 2w3d: Vi1 CHAP: O RESPONSE id 79 Len 28 from "John" 2w3d: Vi1 CHAP: I SUCCESS id 79 Len 4 2w3d: Vi1 PPP: Phase is UP 2w3d: Vi1 IPCP: O CONFREQ [Closed] id 7 Len 10 2w3d: Vi1 IPCP: Address 0.0.0.0 (0x030600000000) 2w3d: Vi1 IPCP: I CONFREQ [REQsent] id 4 Len 10 2w3d: Vi1 IPCP: Address 20.20.2.1 (0x030614140201) 2w3d: Vi1 IPCP: O CONFACK [REQsent] id 4 Len 10 2w3d: Vi1 IPCP: Address 20.20.2.1 (0x030614140201) 2w3d: Vi1 IPCP: I CONFNAK [ACKsent] id 7 Len 10 2w3d: Vi1 IPCP: Address 40.1.1.2 (0x030628010102) 2w3d: Vi1 IPCP: O CONFREQ [ACKsent] id 8 Len 10 2w3d: Vi1 IPCP: Address 40.1.1.2 (0x030628010102) 2w3d: Vi1 IPCP: I CONFACK [ACKsent] id 8 Len 10 2w3d: Vi1 IPCP: Address 40.1.1.2 (0x030628010102) 2w3d: Vi1 IPCP: State is Open 2w3d: Di1 IPCP: Install negotiated IP interface address 40.1.1.2 2w3d: Di1 IPCP: Install route to 20.20.2.1 Router#
Er zijn vier belangrijke punten van mislukking in een PPP-onderhandeling:
Geen respons van het externe apparaat (uw ISP)
Link Control Protocol (LCP) niet geopend
Verificatiefout
IPCP-storing (IP Control Protocol)
Geen respons van uw ISP
Uw ISP die niet reageert, heeft geen probleem omdat u al hebt geverifieerd dat de pakketten op de ATM0-interface in de inkomende richting toenemen. Als u echter pakketten ziet die hoger worden op ATM0 in de inkomende richting en als u een debug ppp onderhandeling uitvoert dan ontvangt u deze uitvoer, neem contact op met uw ISP om te controleren of de pakketten naar de Cisco DSL router worden verzonden.
Router#debug ppp negotiation *Mar 1 04:04:50.718: Vi1 PPP: Treating connection as a callout *Mar 1 04:04:50.718: Vi1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 0 load] *Mar 1 04:04:50.718: Vi1 PPP: No remote authentication for call-out *Mar 1 04:04:50.722: Vi1 LCP: O CONFREQ [Closed] id 1 Len 10 !--- "O" specifies an outbound packet. *Mar 1 04:04:50.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4) *Mar 1 04:04:52.722: Vi1 LCP: TIMEout: State REQsent *Mar 1 04:04:52.722: Vi1 LCP: O CONFREQ [REQsent] id 2 Len 10 !--- "O" specifies an outbound packet. *Mar 1 04:04:52.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4) *Mar 1 04:04:54.722: Vi1 LCP: TIMEout: State REQsent *Mar 1 04:04:54.722: Vi1 LCP: O CONFREQ [REQsent] id 3 Len 10 *Mar 1 04:04:54.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4) *Mar 1 04:04:56.722: Vi1 LCP: TIMEout: State REQsent *Mar 1 04:04:56.722: Vi1 LCP: O CONFREQ [REQsent] id 4 Len 10 *Mar 1 04:04:56.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4) *Mar 1 04:04:58.722: Vi1 LCP: TIMEout: State REQsent *Mar 1 04:04:58.722: Vi1 LCP: O CONFREQ [REQsent] id 5 Len 10 *Mar 1 04:04:58.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4) *Mar 1 04:05:00.722: Vi1 LCP: TIMEout: State REQsent *Mar 1 04:05:00.722: Vi1 LCP: O CONFREQ [REQsent] id 6 Len 10 *Mar 1 04:05:00.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4) *Mar 1 04:05:02.722: Vi1 LCP: TIMEout: State REQsent *Mar 1 04:05:02.722: Vi1 LCP: O CONFREQ [REQsent] id 7 Len 10 !--- "O" specifies an outbound packet. *Mar 1 04:05:02.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4) Router#undebug all
In deze uitvoer zijn er alleen pakketten O, die uitgaande pakketten zijn. Om met succes PPP te onderhandelen, zou er een I inkomende pakket van uw ISP voor elk O pakket moeten zijn verzonden. Als pakketten aan binnenuit groeien maar u ziet niet I pakketten, neem contact op met uw ISP om de pakketten te controleren die naar de router van Cisco DSL worden verzonden.
LCP niet geopend
De LCP die niet wordt geopend, wordt normaal gesproken veroorzaakt door een verkeerde match in PPP-opties. Deze mismatch gebeurt wanneer de Cisco DSL-router een PPP-parameter heeft die is geconfigureerd dat uw ISP niet ondersteunt, of wanneer uw ISP een parameter heeft die is geconfigureerd dat de Cisco DSL-router niet ondersteunt. Deze uitvoer toont een voorbeeld van een mismatch van de PPP-optie:
Router#debug ppp negotiation *Mar 1 04:52:43.254: Vi1 PPP: Treating connection as a callout *Mar 1 04:52:43.258: Vi1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 1 load] *Mar 1 04:52:43.258: Vi1 PPP: No remote authentication for call-out *Mar 1 04:52:43.258: Vi1 LCP: O CONFREQ [Closed] id 3 len 10 *Mar 1 04:52:43.262: Vi1 LCP: MagicNumber 0x31A2F808 (0x050631A2F808) *Mar 1 04:52:43.310: Vi1 LCP: I CONFREQ [REQsent] id 180 Len 14 *Mar 1 04:52:43.310: Vi1 LCP: AuthProto PAP (0x0304C023) *Mar 1 04:52:43.310: Vi1 LCP: MagicNumber 0x39D50E9B (0x050639D50E9B) *Mar 1 04:52:43.314: Vi1 LCP: O CONFNAK [REQsent] id 180 Len 9 !--- PPP option reject *Mar 1 04:52:43.314: Vi1 LCP: AuthProto CHAP (0x0305C22305) !--- PPP option that is rejected *Mar 1 04:52:43.314: Vi1 LCP: I CONFACK [REQsent] id 3 Len 10 *Mar 1 04:52:43.318: Vi1 LCP: MagicNumber 0x31A2F808 (0x050631A2F808) *Mar 1 04:52:43.366: Vi1 LCP: I CONFREQ [ACKrcvd] id 181 Len 14 *Mar 1 04:52:43.366: Vi1 LCP: AuthProto PAP (0x0304C023) *Mar 1 04:52:43.366: Vi1 LCP: MagicNumber 0x39D50E9B (0x050639D50E9B) *Mar 1 04:52:43.370: Vi1 LCP: O CONFNAK [ACKrcvd] id 181 Len 9 !--- PPP option reject *Mar 1 04:52:43.370: Vi1 LCP: AuthProto CHAP (0x0305C22305) !--- PPP option that is rejected *Mar 1 04:52:43.418: Vi1 LCP: I CONFREQ [ACKrcvd] id 182 Len 14 *Mar 1 04:52:43.418: Vi1 LCP: AuthProto PAP (0x0304C023) *Mar 1 04:52:43.418: Vi1 LCP: MagicNumber 0x39D50E9B (0x050639D50E9B) Router#undebug all
Of het nu een I of een O-pakket is, een Configure-Negative-Acknowledge (CONFNAK) is indicatief voor een PPP-configuratie mismatch. Wat dit betekent is dat één kant van de PPP verbinding om een optie van PPP vraagt die de andere kant niet kan of niet wordt gevormd om uit te voeren. Als de Cisco DSL-router de CONFNAK verstuurt (aangegeven door "O CONFNAK"), kan de Cisco DSL-router niet uitvoeren of niet ingesteld worden voor de optie die de ISP verstuurt. Als CONFNAK door uw ISP wordt verzonden (aangegeven door "I CONFNAK"), hebt u een optie ingesteld op de Cisco DSL-router die uw ISP niet bereid is uit te voeren.
De lijn na CONFNAK beschrijft de optie die wordt verworpen. In de uitvoer van dit voorbeeld is de optie CHAP maar het zou elke optie kunnen zijn. De enige plaats op de Cisco DSL-router waar PPP-opties kunnen worden geconfigureerd is interfacetaler 1. Geef de opdracht toe om interfacetaler 1 te tonen om uw interfacetaler 1-configuratie te bekijken.
Als uw ISP de I CONFNAK verstuurt, zoekt u opdrachten onder interfacetaler 1 die overeenkomen met de lijn na de CONFNAK en verwijdert u deze. Als de Cisco DSL-router de OK-CONFNAK verstuurt, voegt u een opdracht toe aan interfacetaler 1 om PPP met uw ISP correct te onderhandelen. In het geval van de router die pakketten verzenden, kunt u de Cisco TAC moeten bellen om te bepalen welke opdracht(en) op de Cisco DSL-router moet worden geactiveerd.
Verificatiefout
Een authenticatiefout treedt op wanneer uw ISP uw PPP gebruikersnaam of wachtwoord niet kan authenticeren. Er zijn twee scenario's waarin dit kan gebeuren. Het eerste scenario is een authenticatietype mismatch, die wordt veroorzaakt wanneer u de router niet juist aanpast. Alle in dit document opgesomde authenticatieconfiguraties nemen zowel PAP- als CHAP-verificatietypen in aanmerking. Voor configuratieflexibiliteit moet u zowel CHAP als PAP ingesteld hebben. Als u beide niet hebt ingesteld, kunt u uitvoer van een debug ppp-opdracht zien zoals in deze uitvoer:
Router#debug ppp negotiation 00:34:29: Vi1 LCP:O CONFREQ [REQsent] id 53 Len 15 00:34:29: Vi1 LCP: AuthProto CHAP (0x0305C22305) !--- Sends CHAP requests 00:34:29: Vi1 LCP: MagicNumber 0x01B63483 (0x050601B63483) 00:34:29: Vi1 LCP: I CONFREQ [REQsent] id 252 Len 14 00:34:29: Vi1 LCP: AuthProto PAP (0x0304C023) !--- Receives PAP requests from the service provider 00:34:29: Vi1 LCP: MagicNumber 0xBC5233F9 (0x0506BC5233F9) 00:34:29: Vi1 LCP: O CONFREJ [REQsent] id 252 Len 8 Router#undebug all
of
Router#debug ppp negotiation 00:45:44: Vi1 LCP: I CONFREQ [Listen] id 141 Len 15 00:45:44: Vi1 LCP: AuthProto CHAP (0x0305C22305) !--- Receives CHAP requests from the service provider 00:45:44: Vi1 LCP: MagicNumber 0xBC5C7DDC (0x0506BC5C7DDC) 00:45:44: Vi1 LCP: O CONFREQ [Listen] id 255 Len 14 00:45:44: Vi1 LCP: AuthProto PAP (0x0304C023) !--- Sends out PAP requests Router#undebug all !--- Turn off ppp debug
Om beide problemen van de authenticatiewanverhouding te corrigeren, verwijs naar de juiste PPPoA implementatieoptie configuratie en pas PPP authenticatie aan.
Het tweede authenticatieprobleem scenario dat u kunt tegenkomen is een incorrecte naam van de PAP of een wachtwoord. Om te bepalen of dit het probleem is, geeft de opdracht de PPP-onderhandeling af. Aangenomen dat uw router is geconfigureerd voor zowel Challenge Handshake Authentication Protocol (CHAP) als Password Authentication Protocol (PAP), zoals de configuratie die eerder in deze gids is geschetst, zal uw ISP mogelijk geen PAP-verificatie gebruiken.
Om de verificatie te bepalen die door uw ISP wordt gebruikt, controleert u de opties in het I CONFREQ-pakket dat u van uw ISP hebt ontvangen. Als dit pakket wordt gevolgd door een optie genaamd AuthProto PAP, gebruikt u PAP. Als de I CONFREQ wordt gevolgd door een optie genaamd AuthProto CHAP, gebruikt u CHAP en moet u verder gaan Hoe weet ik of mijn CHAP gebruikersnaam en wachtwoord juist zijn?
Nadat u hebt bevestigd dat uw ISP PAP gebruikt, geeft u de opdracht debug ppp onderhandeling uit om te bevestigen dat uw PAP-gebruikersnaam en -wachtwoord juist zijn.
Router#debug ppp negotiation *Mar 2 00:50:15.741: Vi1 PPP: Treating connection as a callout *Mar 2 00:50:15.745: Vi1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 1 load] *Mar 2 00:50:15.745: Vi1 PPP: No remote authentication for call-out *Mar 2 00:50:15.745: Vi1 LCP: O CONFREQ [Closed] id 177 Len 10 *Mar 2 00:50:15.745: Vi1 LCP: MagicNumber 0x35EB5D4F (0x050635EB5D4F) *Mar 2 00:50:15.789: Vi1 LCP: I CONFACK [REQsent] id 177 Len 10 *Mar 2 00:50:15.793: Vi1 LCP: MagicNumber 0x35EB5D4F (0x050635EB5D4F) *Mar 2 00:50:17.241: Vi1 LCP: I CONFREQ [ACKrcvd] id 203 Len 14 *Mar 2 00:50:17.241: Vi1 LCP: AuthProto PAP (0x0304C023) *Mar 2 00:50:17.241: Vi1 LCP: MagicNumber 0x3E1D1E5E (0x05063E1D1E5E) *Mar 2 00:50:17.245: Vi1 LCP: O CONFACK [ACKrcvd] id 203 Len 14 *Mar 2 00:50:17.245: Vi1 LCP: AuthProto PAP (0x0304C023) *Mar 2 00:50:17.245: Vi1 LCP: MagicNumber 0x3E1D1E5E (0x05063E1D1E5E) *Mar 2 00:50:17.249: Vi1 LCP: State is Open *Mar 2 00:50:17.249: Vi1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 1 load] *Mar 2 00:50:17.249: Vi1 PAP: O AUTH-REQ id 9 Len 14 from "cisco" !--- "cisco" is the PAP username configured on this DSL router. *Mar 2 00:50:17.297: Vi1 PAP: I AUTH-NAK id 9 Len 27 msg is "Authentication failure" *Mar 2 00:50:17.301: Vi1 LCP: I TERMREQ [Open] id 204 Len 4 *Mar 2 00:50:17.301: Vi1 LCP: O TERMACK [Open] id 204 Len 4 *Mar 2 00:50:17.305: Vi1 PPP: Phase is TERMINATING [0 sess, 1 load]u *Mar 2 00:50:19.305: Vi1 LCP: TIMEout: State TERMsent *Mar 2 00:50:19.305: Vi1 LCP: State is Closed *Mar 2 00:50:19.305: Vi1 PPP: Phase is DOWN [0 sess, 1 load]
Als u een probleem hebt met de PAP-verificatie, ziet u de LCP-status openen. Direct na de LCP status-wijziging dient u te zien dat PPP in een Verificatie-fase gaat. Als een van de volgende twee regels I AUTH-NAK bevat, is ofwel uw PAP-gebruikersnaam of PAP-wachtwoord onjuist. Op dit punt, moet u uw gebruikersnaam en wachtwoord van de PAP aan het veranderen met deze reeks opdrachten. Merk op dat uw PAP-gebruikersnaam en -wachtwoord hoofdlettergevoelig zijn.
Router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router(config)#interface dialer 1 Router(config-if)#ppp pap sent-usernamepassword Router(config-if)#end Router#write memory
Nadat u hebt bevestigd dat uw ISP CHAP gebruikt, geeft u de opdracht debug ppp onderhandeling uit om te bevestigen dat uw gebruikersnaam en wachtwoord voor CHAP juist zijn.
Router#debug ppp negotiation *Mar 3 02:51:47.287: Vi1 PPP: Treating connection as a callout *Mar 3 02:51:47.287: Vi1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 1 load] *Mar 3 02:51:47.291: Vi1 PPP: No remote authentication for call-out *Mar 3 02:51:47.291: Vi1 LCP: O CONFREQ [Closed] id 188 Len 10 *Mar 3 02:51:47.291: Vi1 LCP: MagicNumber 0x3B821FF1 (0x05063B821FF1) *Mar 3 02:51:47.339: Vi1 LCP: I CONFREQ [REQsent] id 204 Len 15 *Mar 3 02:51:47.343: Vi1 LCP: AuthProto CHAP (0x0305C22305) *Mar 3 02:51:47.343: Vi1 LCP: MagicNumber 0x43B3F393 (0x050643B3F393) *Mar 3 02:51:47.343: Vi1 LCP: O CONFACK [REQsent] id 204 Len 15 *Mar 3 02:51:47.347: Vi1 LCP: AuthProto CHAP (0x0305C22305) *Mar 3 02:51:47.347: Vi1 LCP: MagicNumber 0x43B3F393 (0x050643B3F393) *Mar 3 02:51:47.347: Vi1 LCP: I CONFACK [ACKsent] id 188 Len 10 *Mar 3 02:51:47.351: Vi1 LCP: MagicNumber 0x3B821FF1 (0x05063B821FF1) *Mar 3 02:51:47.351: Vi1 LCP: State is Open *Mar 3 02:51:47.351: Vi1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 1 load] *Mar 3 02:51:47.395: Vi1 CHAP: I CHALLENGE id 1 Len 32 from "6400-2-NRP3" *Mar 3 02:51:47.395: Vi1 CHAP: Using alternate hostname cisco *Mar 3 02:51:47.399: Vi1 CHAP: Username 6400-2-NRP3 not found *Mar 3 02:51:47.399: Vi1 CHAP: Using default password *Mar 3 02:51:47.399: Vi1 CHAP: O RESPONSE id 1 Len 26 from "cisco" !--- "cisco" is the CHAP username configured on this DSL router. *Mar 3 02:51:47.447: Vi1 CHAP: I FAILURE id 1 Len 26 MSG is "Authentication failure" *Mar 3 02:51:47.447: Vi1 LCP: I TERMREQ [Open] id 205 Len 4 *Mar 3 02:51:47.451: Vi1 LCP: O TERMACK [Open] id 205 Len 4 *Mar 3 02:51:47.451: Vi1 PPP: Phase is TERMINATING [0 sess, 0 load] *Mar 3 02:51:49.451: Vi1 LCP: TIMEout: State TERMsent *Mar 3 02:51:49.451: Vi1 LCP: State is Closed *Mar 3 02:51:49.451: Vi1 PPP: Phase is DOWN [0 sess, 0 load] Router#undebug all
Als u een probleem hebt met de verificatie van CHAP, ziet u de LCP-status openen. Direct na de LCP status-wijziging dient u te zien dat PPP in een Verificatie-fase gaat. Vanaf dit punt zie je een reeks CHAP-lijnen. Als het laatste van deze regels mij fout laat zien, heb je de verkeerde gebruikersnaam en het wachtwoord van CHAP. Gebruik deze reeks opdrachten om de gebruikersnaam en het wachtwoord voor CHAP te corrigeren. Let op dat uw gebruikersnaam en wachtwoord hoofdlettergevoelig zijn.
Router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router(config)#interface dialer 1 Router(config-if)#ppp chap hostnameRouter(config-if)#ppp chap password Router(config-if)#end Router#write memory
Dit voorbeeld toont een succesvolle onderhandeling van het KAP.
Router#debug ppp negotiation <... snipped ...> *Mar 3 03:30:09.335: Vi1 LCP: State is Open *Mar 3 03:30:09.335: Vi1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 1 load] *Mar 3 03:30:09.379: Vi1 CHAP: I CHALLENGE id 41 len 32 from "6400-2-NRP3" *Mar 3 03:30:09.379: Vi1 CHAP: Using alternate hostname cisco *Mar 3 03:30:09.379: Vi1 CHAP: Username 6400-2-NRP3 not found *Mar 3 03:30:09.383: Vi1 CHAP: Using default password *Mar 3 03:30:09.383: Vi1 CHAP: O RESPONSE id 41 Len 26 from "cisco" *Mar 3 03:30:09.431: Vi1 CHAP: I SUCCESS id 41 Len 4 !--- CHAP negotiation was a success. *Mar 3 03:30:09.431: Vi1 PPP: Phase is UP [0 sess, 1 load] <... snipped ...> Router#undebug all
Dit voorbeeld toont een succesvolle PAP onderhandeling.
Router#debug ppp negotiation <... snipped ...> *Mar 3 03:33:19.491: Vi1 LCP: State is Open *Mar 3 03:33:19.491: Vi1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 0 load] *Mar 3 03:33:19.495: Vi1 PAP: O AUTH-REQ id 255 Len 16 from "cisco" *Mar 3 03:33:19.539: Vi1 PAP: I AUTH-ACK id 255 Len 5 *Mar 3 03:33:19.539: Vi1 PPP: Phase is UP [0 sess, 0 load] !--- PAP negotiation was a success. <... snipped ...> Router#undebug all
Toegang tot slechts sommige webpagina's is een algemeen probleem wanneer u een PPPoE-client op een router voert. Door ontwerp kan PPPoE een MTU van maximaal 1492 bytes ondersteunen. Daarom moet u ervoor zorgen dat eindapparaten frames verzenden die niet groter zijn dan 1492 bytes. Het beperken van de MTU tot 1492 bytes kan een probleem zijn omdat de meeste pc's en werkstations van de eindgebruiker een standaard MTU van 1500 bytes hebben.
Er zijn twee opties om de grootte van de MTU aan te passen: Pas de grootte van MTU aan op de router en pas de grootte van MTU aan op de PC.
Belangrijke opmerkingen:
Deze configuratieopdrachten werken alleen als u NAT (Network Address Translation) of PAT (Port Address Translation) op de Cisco DSL-router gebruikt.
De opdracht ip adapt-mss in Cisco IOS® softwarerelease 12.2(2)XH is veranderd in ip TCP-instelling-mss <mss waarde>. Deze verandering is gedocumenteerd in Releaseopmerkingen voor Cisco 800 Series routers en Cisco 8200 Series routers voor Cisco IOS-softwarerelease 12.2(2)XH.
! vpdn enable no vpdn logging ! vpdn-group pppoe request-dialin protocol pppoe ! interface ethernet0 no shut ip address <ip address> <subnet mask> ip adjust-mss 1452 !--- The TCP MSS command requires an MSS of 1452, not 1492. ip nat inside no ip directed-broadcast ! interface atm0 no shut no ip address no ip directed-broadcast no atm ilmi-keepalive bundle-enable ! interface atm0.1 point-to-point no ip directed-broadcast pvc <vpi/vci> pppoe-client dial-pool-number 1 ! ! interface dialer1 ip address negotiated mtu 1492 ip nat outside encapsulation ppp dialer pool 1 ppp chap hostname <username> ppp chap password <password> ppp pap sent-username <username> password <password> ! ip nat inside source list 1 interface dialer1 overload ! ip classless ip route 0.0.0.0 0.0.0.0 dialer1 access-list 1 permit0.0.255.255 !
Voltooi deze stappen om de grootte van de MTU op de pc te wijzigen. De registratiewijziging wordt opgeslagen wanneer de procedure is voltooid.
Opmerking: De Dr. TCP voorziening is compatibel met alle op Windows gebaseerde PC's.
Download de nieuwste versie van de Dr. TCP voorziening .
Verfris uw browser pagina om ervoor te zorgen dat de pagina actueel is.
Start de dr.TCP voorziening.
Kies in het menu uw Ethernet-adapter.
Type 1492 op het gebied van de MTU.
Klik op Toepassen om de wijziging op te slaan en vervolgens op Afsluiten.
Herstart de PPPoE PC client.
U hoeft de voorziening slechts eenmaal per PPPoE-client-pc te gebruiken.
Als u de grootte van MTU met Dr TCP of op de router van Cisco DSL verandert en nog niet in staat bent om bepaalde websites te bladeren, pas de grootte van MTU opnieuw aan. Verander de grootte van MTU in 1452 in Dr. TCP, of verander de waarde van MSS op de router van Cisco DSL aan 1412. Als deze formaten te groot zijn, blijf u de grootte van de MTU verlagen tot u een basislijn van 1400 voor Dr. TCP of 1360 voor MSS aanpast op de router van Cisco DSL.