De betekenis van debug ppp-onderhandeling

Inleiding

In met een knop samenhangende toepassingen is PPP het meest gebruikte insluitingstype. PPP staat twee machines op een point-to-point communicatieverbinding toe om verschillende parameters te onderhandelen voor verificatie, compressie en de Layer 3 (L3) protocollen, zoals IP. Een mislukking in de PPP onderhandeling tussen twee routers veroorzaakt een defect.

De opdracht debug ppp onderhandeling stelt u in staat om de PPP onderhandelingstransacties te bekijken, het probleem of de fase te identificeren wanneer de fout optreedt, en een resolutie te ontwikkelen. Nochtans, het is zeer belangrijk dat u de opdrachtoutput van de debug ppp onderhandeling begrijpt. Dit document biedt een uitgebreide methode om debug van PPP-onderhandeling te lezen.

Voorwaarden

Vereisten

Lezers van dit document moeten ervoor zorgen dat aan deze voorwaarden wordt voldaan:

• PPP moet op de interfaces op beide routers worden ingeschakeld. Geef de opdracht insluitingspremie op om dit te bereiken.

• Geef deze opdracht uit om de tijden van de volgende gebeurtenis in de router van Milmilliseconde toe te staan:

  Router(config)# service timestamp debug datetime msec
  

  Zie Belangrijke informatie over Debug Commands voor meer informatie over debug-opdrachten.

Opmerking: PPP-onderhandeling tussen twee peers kan niet starten tenzij de onderste laag (ISDN, fysieke interface, inbellijn, enzovoort) onder PPP-functies perfect werkt. Als u PPP over ISDN bijvoorbeeld wilt uitvoeren, moeten alle ISDN-lagen omhoog zijn; anders start PPP niet.

Gebruikte componenten

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

Conventies

Raadpleeg Cisco Technical Tips Conventions (Conventies voor technische tips van Cisco) voor meer informatie over documentconventies.

Fases van PPP-onderhandeling

De link gaat door verschillende fasen in het proces van PPP-onderhandeling, zoals in deze tabel wordt getoond. Het eindresultaat is dat PPP of omhoog of omlaag is.

*Mar  3 23:32:50.296: BR0:1 PPP: Phase is DOWN

*Mar  3 23:32:06.884: BR0:1 PPP: Phase is ESTABLISHING

*Mar 3 23:32:06.952: BR0:1 PPP: Phase is AUTHENTICATING

*Mar  3 23:42:53.412: BR0:1 PPP: Phase is UP

*Mar  3 23:43:23.256: BR0:1 PPP: Phase is TERMINATING

^{1. LCP = Link Control Protocol}

^{2. CHAP = Challenge Handshake Authentication Protocol}

^{3. PAP = Wachtwoordverificatie-protocol}

^{4. NCP = Network Control Protocol}

In dit schema is de PPP-faseovergang aangegeven:

PPP-onderhandelingspakketten: Een beschrijving

Deze tabel bevat een beschrijving van PPP-onderhandelingspakketten die in zowel de LCP- als de NCP-onderhandeling worden gebruikt:

^{1. NAK = negatieve erkenning}

^{2. ACK = kennis}

Opmerking: Elke peer kan CONFREQ's verzenden met de optie of waarde die de peer wil ondersteunen. Dit kan ertoe leiden dat de opties waarover in elke richting is onderhandeld, anders zijn. Het is bijvoorbeeld mogelijk dat de ene kant de peer wil authentiseren, terwijl de andere niet.

LCP, verificatie en NCP stadium

Binnen enkele van de eerder beschreven PPP fasen, gaat PPP ook in specifieke fasen zoals LCP onderhandeling, Verificatie, en NCP onderhandeling. Raadpleeg voor meer informatie RFC 1548 en RFC 1661 .

LCP (verplichte fase)

LCP is een fase waarin parameters om de datalink-verbinding op te zetten, te configureren en te testen worden uitgevoerd. Een LCP-status met open armen betekent dat LCP met succes is voltooid terwijl een LCP-status met gesloten deuren een LCP-storing aangeeft.

In dit schema is een conceptuele weergave van een LCP-handdruk te zien:

De LCP onderhandeling gebruikt ook een parameter die MagicNumber wordt genoemd, die wordt gebruikt om te bepalen of de link achteruit loopt. Een willekeurige string wordt verzonden over de link en, als dezelfde waarde wordt teruggegeven, bepaalt de router of de link achteruit loopt.

Verificatie (optionele fase per standaard)

In deze fase wordt de authenticatie uitgevoerd met het authenticatieprotocol (CHAP of PAP) dat overeengekomen is in LCP-onderhandeling. Raadpleeg voor PAP-gerelateerde informatie het PPP-protocol voor wachtwoordverificatie en -probleemoplossing (PAP).

Raadpleeg voor informatie over CHAP het begrip en het configureren van PPP CHAP-verificatie.

Opmerking: Verificatie is optioneel en PPP voert alleen dit stadium in als het moet authenticeren.

NCP (verplichte fase)

Deze fase wordt gebruikt om verschillende netwerk-laag protocollen in te stellen en te configureren. Het meest voorkomende L3-protocol dat is onderhandeld, is IP. De routers wisselen IP Control Protocol (IPCP)-berichten uit om te onderhandelen over opties die specifiek zijn voor het protocol (IP in dit voorbeeld).

RFC 1332 zegt dat IPCP onderhandelt over twee opties: compressie en IP adrestoewijzing. IPCP wordt echter ook gebruikt voor het doorgeven van netwerkgerelateerde informatie zoals primaire en back-up Windows Name Service (WINS) en Domain Name System (DNS)-servers.

De onderhandeling vindt plaats met het gebruik van CONF-berichten, zoals beschreven in de PPP-onderhandelingspakketten: Een gedeelte met de beschrijving van dit document.

Problemen oplossen met debug PPP-onderhandeling

Wanneer u de opdrachtoutput van de debug ppp onderhandeling leest voor het oplossen van problemen, volg deze instructies:

1. Identificeer de faseovergangen in de opdrachtoutput debug. Bepaal de verste fase van de verbinding die tot stand is gebracht, zoals UP of AUTHENTICATING. Dit kan u helpen de fase te identificeren waarin de verbinding faalde. Voor meer informatie over de fasen, zie de fasen van de PPP-onderhandeling.

2. Kijk voor de fase waarin de fout is opgetreden naar berichten die erop wijzen dat LCP, verificatie of NCP (naar gelang van toepassing) succesvol zijn:

   • De LCP-status moet open zijn. U kunt ook de laatste inkomende en uitgaande CONFACK-berichten bekijken om te controleren of de parameters die u nodig hebt, zijn onderhandeld.

   • Verificatie moet succesvol zijn. Als u tweevoudige authenticatie gebruikt, dan moet elke transactie succesvol zijn. Voor meer informatie over het opsporen van problemen in PPP-verificatie, zie Problemen oplossen PPP-verificatie (CHAP of PAP).

   • De IPCP-status moet open zijn. Controleer dat de adressering correct is en dat een route naar de peer geïnstalleerd is.

Lees de debug ppp onderhandeling

De meeste lijnen in de opdrachtoutput van de debug ppp worden gekarakteriseerd door:

1. De timestamp-Milound timestamps is handig. Zie het gedeelte Voorwaarden van dit document voor meer informatie.

2. Interface en interfacenummer-Dit veld is handig wanneer u verbindingen wilt beveiligen met meerdere verbindingen, of wanneer de verbinding via meerdere interfaces verloopt. Bijvoorbeeld, bepaalde verbindingen (zoals multilink vraag) worden gecontroleerd door de fysieke interface in het begin, maar worden later gecontroleerd door de dialerinterface of de virtuele toegangsinterface.

3. Het type PPP bericht-Dit veld geeft aan of de regel een algemeen PPP-, LCP-, CHAP-, PAP- of IPCP-bericht is.

4. Richting van het bericht—Een die ik op een inkomend pakket aangeeft en een 00 aangeeft, wijst op een uitgaand pakket. Dit veld kan worden gebruikt om te bepalen of het bericht door de router gegenereerd of ontvangen is.

5. Bericht - Dit veld bevat de specifieke transactie waarover wordt onderhandeld.

6. ID-Dit veld wordt gebruikt om verzoekberichten aan de juiste responsberichten aan te passen en te coördineren. U kunt het veld ID gebruiken om een reactie op een inkomend bericht te associëren. Deze optie is vooral handig wanneer het inkomende bericht en de reactie ver van elkaar verwijderd zijn in de debug-uitvoer.

7. Lengte-Het lengteveld definieert de lengte van het informatieveld. Dit veld is niet belangrijk voor problemen oplossen in het algemeen.

Opmerking: velden 4 tot en met 7 kunnen niet in alle PPP-berichten verschijnen, afhankelijk van het doel van het bericht.

Opmerking: Dit voorbeeld illustreert de velden:

Uitvoer van voorbeelddebug-onderhandeling

Dit is een geannoteerde beschrijving van de opdrachtoutput van debug ppp:

maui-soho-01#debug ppp negotiation
PPP protocol negotiation debugging is on
maui-soho-01#
*Mar  1 00:06:36.645: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up

!--- The Physical Layer (BRI Interface) is up. Only now can PPP !--- negotiation begin.

*Mar  1 00:06:36.661: BR0:1 PPP: Treating connection as a callin
*Mar  1 00:06:36.665: BR0:1 PPP: Phase is ESTABLISHING, Passive Open 
[0 sess, 0 load]

!--- The PPP Phase is ESTABLISHING. LCP negotiation now occurs.

*Mar  1 00:06:36.669: BR0:1 LCP: State is Listen
*Mar  1 00:06:37.034: BR0:1 LCP: I CONFREQ [Listen] id 7 len 17

!--- This is the incoming CONFREQ. The ID field is 7.

*Mar  1 00:06:37.038: BR0:1 LCP:    AuthProto PAP (0x0304C023)
*Mar  1 00:06:37.042: BR0:1 LCP:    MagicNumber 0x507A214D (0x0506507A214D)
*Mar  1 00:06:37.046: BR0:1 LCP:    Callback 0  (0x0D0300)

!--- The peer has requested: !--- Option: Authentication Protocol, Value: PAP !--- Option: MagicNumber (This is used to detect loopbacks and is always sent.) !--- Option: Callback, Value: 0 (This is for PPP Callback; MS Callback uses 6.)

*Mar  1 00:06:37.054: BR0:1 LCP: O CONFREQ [Listen] id 4 len 15

!--- This is an outgoing CONFREQ, with parameters for the peer to implement. !--- Note that the ID Field is 4, so this is not related to the previous !--- CONFREQ message.

*Mar  1 00:06:37.058: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
*Mar  1 00:06:37.062: BR0:1 LCP:    MagicNumber 0x1081E7E1 (0x05061081E7E1)

!--- This router requests: !--- Option: Authentication Protocol, Value: CHAP !--- Option: MagicNumber (This is used to detect loopbacks and is always sent.)

*Mar  1 00:06:37.066: BR0:1 LCP: O CONFREJ [Listen] id 7 len 7

!--- This is an outgoing CONFREJ for message with Field ID 7. !--- This is the response to the CONFREQ received first.

*Mar  1 00:06:37.070: BR0:1 LCP:    Callback 0  (0x0D0300)

!--- The option that this router rejects is Callback. !--- If the router wanted to do MS Callback rather than PPP Callback, it !--- would have sent a CONFNAK message instead.

*Mar  1 00:06:37.098: BR0:1 LCP: I CONFACK [REQsent] id 4 len 15

!--- This is an incoming CONFACK for a message with Field ID 4.

*Mar  1 00:06:37.102: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
*Mar  1 00:06:37.106: BR0:1 LCP:    MagicNumber 0x1081E7E1 (0x05061081E7E1)

!--- The peer can support all requested parameters.

*Mar  1 00:06:37.114: BR0:1 LCP: I CONFREQ [ACKrcvd] id 8 len 14

!--- This is an incoming CONFREQ message; the ID field is 8. !--- This is a new CONFREQ message from the peer in response to the CONFREJ id:7.

*Mar  1 00:06:37.117: BR0:1 LCP:    AuthProto PAP (0x0304C023)
*Mar  1 00:06:37.121: BR0:1 LCP:    MagicNumber 0x507A214D (0x0506507A214D)

!--- The peer has requested: !--- Option: Authentication Protocol, Value: PAP !--- Option: MagicNumber (This is used to detect loopbacks and is always sent.)

*Mar  1 00:06:37.125: BR0:1 LCP: O CONFNAK [ACKrcvd] id 8 len 9

!--- This is an outgoing CONFNACK for a message with Field ID 8.

*Mar  1 00:06:37.129: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)

!--- This router recognizes the option Authentication Protocol, !--- but does not accept the value PAP. In the CONFNAK message, !--- it suggests CHAP instead.

*Mar  1 00:06:37.165: BR0:1 LCP: I CONFREQ [ACKrcvd] id 9 len 15

!--- This is an incoming CONFREQ message with Field ID 9.

*Mar  1 00:06:37.169: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
*Mar  1 00:06:37.173: BR0:1 LCP:    MagicNumber 0x507A214D (0x0506507A214D)

!--- CHAP authentication is requested.

*Mar  1 00:06:37.177: BR0:1 LCP: O CONFACK [ACKrcvd] id 9 len 15

!--- This is an outgoing CONFACK for a message with Field ID 9.

*Mar  1 00:06:37.181: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
*Mar  1 00:06:37.185: BR0:1 LCP:    MagicNumber 0x507A214D (0x0506507A214D)
*Mar  1 00:06:37.189: BR0:1 LCP: State is Open

!--- This indicates that the LCP state is Open.

*Mar  1 00:06:37.193: BR0:1 PPP: Phase is AUTHENTICATING, by both [0 sess, 0 load]

!--- The PPP Phase is AUTHENTICATING. PPP Authentication occurs now. !--- Two-way authentication is now performed (indicated by the both keyword).

*Mar  1 00:06:37.201: BR0:1 CHAP: O CHALLENGE id 4 len 33 from "maui-soho-01"

!--- This is the outgoing CHAP Challenge. !--- In LCP the routers had agreed upon CHAP as the authentication protocol.

*Mar  1 00:06:37.225: BR0:1 CHAP: I CHALLENGE id 3 len 33 from "maui-soho-03"

!--- This is an incoming Challenge message from the peer.

*Mar  1 00:06:37.229: BR0:1 CHAP: Waiting for peer to authenticate first
*Mar  1 00:06:37.237: BR0:1 CHAP: I RESPONSE id 4 len 33 from "maui-soho-03"

!--- This is an incoming response from the peer.

*Mar  1 00:06:37.244: BR0:1 CHAP: O SUCCESS id 4 len 4

!--- This router has successfully authenticated the peer.

*Mar  1 00:06:37.248: BR0:1 CHAP: Processing saved Challenge, id 3
*Mar  1 00:06:37.260: BR0:1 CHAP: O RESPONSE id 3 len 33 from "maui-soho-01"
*Mar  1 00:06:37.292: BR0:1 CHAP: I SUCCESS id 3 len 4

!--- This is an incoming Success message. Each side has !--- successfully authenticated the other.

*Mar  1 00:06:37.296: BR0:1 PPP: Phase is UP [0 sess, 0 load]

!--- The PPP status is now UP. NCP (IPCP) negotiation begins.

*Mar  1 00:06:37.304: BR0:1 IPCP: O CONFREQ [Closed] id 4 len 10
*Mar  1 00:06:37.308: BR0:1 IPCP:    Address 172.22.1.1 (0x0306AC160101)

!--- This is an outgoing CONFREQ message. It indicates that !--- the local machine address is 172.22.1.1.

*Mar  1 00:06:37.312: BR0:1 CDPCP: O CONFREQ [Closed] id 4 len 4
*Mar  1 00:06:37.320: BR0:1 CDPCP: I CONFREQ [REQsent] id 4 len 4
*Mar  1 00:06:37.324: BR0:1 CDPCP: O CONFACK [REQsent] id 4 len 4

!--- These messages are for CDP Control Protocol (CDPCP).

*Mar  1 00:06:37.332: BR0:1 IPCP: I CONFREQ [REQsent] id 4 len 10
*Mar  1 00:06:37.336: BR0:1 IPCP:    Address 172.22.1.2 (0x0306AC160102)

!--- This is an incoming CONFREQ message that indicates that the peer !--- address is 172.22.1.2. An address of 0.0.0.0 indicates that the peer !--- does not have an address and requests the local router to provide it !--- with an address in IPCP negotiation.

*Mar  1 00:06:37.344: BR0:1 IPCP: O CONFACK [REQsent] id 4 len 10
*Mar  1 00:06:37.348: BR0:1 IPCP:    Address 172.22.1.2 (0x0306AC160102)
*Mar  1 00:06:37.356: BR0:1 IPCP: I CONFACK [ACKsent] id 4 len 10
*Mar  1 00:06:37.360: BR0:1 IPCP:    Address 172.22.1.1 (0x0306AC160101)
*Mar  1 00:06:37.363: BR0:1 IPCP: State is Open

!--- The IPCP state is Open. Note that in the IPCP negotiation, each side !--- accepted the IP address of the peer, and one was assigned to the peer.

*Mar  1 00:06:37.371: BR0:1 CDPCP: I CONFACK [ACKsent] id 4 len 4
*Mar  1 00:06:37.375: BR0:1 CDPCP: State is Open

!--- This indicates that the CDPCP state is Open.

*Mar  1 00:06:37.387: BR0 IPCP: Install route to 172.22.1.2

!--- A route to the peer is installed.

*Mar  1 00:06:38.288: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1,
 changed state to up
*Mar  1 00:06:42.609: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to
 maui-soho-03

Lijst van termen en gemeenschappelijke berichten

Algemeen

CONFREQ (configuratie-aanvraag):

Wanneer de onderste laag beschikbaar wordt (Omhoog), wordt CONFREQ verzonden om de eerste PPP fase (LCP fase) te starten. Het wordt in LCP- en NCP-fasen gebruikt om de verbinding te configureren. Om een verbinding met de peer te openen, geeft het apparaat dit bericht samen met de configuratieopties en de waarden door de afzender willen dat de peer wordt ondersteund. Alle opties en waarden worden tegelijkertijd overeengekomen. Als de peer met een CONFREJ of CONFNAK bericht reageert, verstuurt de router een andere CONFREQ met een andere reeks opties of waarden.

CONFACE (configuratie-bevestiging):

Als alle opties in het CONFREQ-bericht herkend kunnen worden en alle waarden acceptabel zijn, dan stuurt de router een CONFACK-bericht door.

CONFREJ (afwijzing instellen):

Als een bepaalde configuratieoptie in CONFREQ niet acceptabel of niet herkend is, reageert de router met een CONFREJ-bericht. De onaanvaardbare optie (van de CONFREQ) is opgenomen in de CONFREJ-boodschap.

CONFNAK (negatieve bevestiging configureren):

Als de ontvangen configuratieoptie herkend en aanvaardbaar is, maar een of andere waarde niet acceptabel is, geeft de router een CONFNAK-bericht door. De router voegt de optie en waarde toe die zij in het CONFNAK-bericht kan accepteren zodat de peer die optie in het volgende CONFREQ-bericht kan opnemen.

ECHOREQ (Echo-aanvraag) en ECHOREP (Echo-antwoord):

PPP gebruikt keepalives om de integriteit van de verbinding te behouden. Deze keepalives zijn het ECHOREQ frame dat naar externe PPP peer wordt verzonden en de externe PPP peer moet met een ECHOREP frame reageren na ontvangst van een ECHOREQ frame. Standaard als de router vijf ECHOREP-frames mist, wordt de link neergehaald en PPP verlaagd.

TERMREQ (afsluitverzoek):

Dit frame geeft aan dat de PPP-peer die dit frame heeft verzonden, de PPP-verbinding beëindigt.

TERMACK (afsluitbevestiging):

Dit bericht wordt verzonden als antwoord op het TERMREQ - bericht. Hiermee wordt de PPP-verbinding gesloten.

BEËINDIGEN

Dit bericht geeft aan dat de PPP-verbinding is verlaagd. Een LCP- of NCP-verbinding kan worden afgesloten:

• bij administratieve afsluiting (alleen LCP).

• wanneer het lagere niveau buiten dienst gaat (inbellijn, ISDN, etc.).

• wanneer de onderhandelingen voorbij zijn .

• on line loop detectie.

LCP

ACCM (Asynchrone controlekaart):

Dit is een van de door LCP onderhandelde opties binnen het CONFREQ-kader. ACCM stelt de tekenontsnappingssequenties in. ACCM vertelt de poort om gespecificeerde besturingstekens binnen de gegevensstroom te negeren. Als de router aan het andere eind van de verbinding geen ACCM onderhandeling steunt, wordt de haven gedwongen om FFFFFF te gebruiken. Geef in dat geval deze opdracht op:

ppp accm match 000a000

ACFC (Adres en Control Veldcompressie):

ACFC is een LCP-optie waarmee endpoints berichten efficiënter heen en weer kunnen versturen.

AutoProto (Verificatieprotocol):

AuthProto is het in het CONFREQ-kader overeengekomen type verificatieprotocol tussen beide PPP-verbindingspers voor gebruik in de verificatiefase. Als geen PPP-verificatie wordt geconfigureerd, wordt deze uitvoer niet gezien in door het CONFREQ-kader onderhandelde parameters. De mogelijke waarden zijn CHAP of PAP.

Terugbellen "#":

Dit bericht geeft aan dat er onderhandeld is over de callback optie. Het nummer na de syntax geeft aan welke callback optie is onderhandeld. Het getal 0 is normaal PPP-callback, terwijl het nummer 6 de Microsoft callback-optie aangeeft (die automatisch beschikbaar is in Cisco IOS® softwarerelease 11.3(2)T of hoger).

CHAP (Challenge Handshake Authentication Protocol):

Dit bericht geeft aan dat het verificatieprotocol waarover onderhandeld wordt, CHAP is.

EndpointDisc (end-point Discriminator):

Dit is een LCP optie die wordt gebruikt om een PPP peer in PPP multilink-verbinding te identificeren. Raadpleeg voor meer informatie Criteria voor het Namen van multilink-PPP-bundels.

LCP: Staat staat open

Dit bericht geeft aan dat de LCP-onderhandeling is voltooid.

LQM (Link Quality Monitoring)

LQM is beschikbaar op alle seriële interfaces die PPP uitvoeren. LQM controleert de verbindingskwaliteit en neemt de link omlaag wanneer de kwaliteit onder een ingesteld percentage zakt. De percentages worden berekend voor zowel de inkomende als de uitgaande richtingen. De uitgaande kwaliteit wordt berekend door het totale aantal pakketten en bytes te vergelijken die worden verzonden met het totale aantal pakketten en bytes die door de peer worden ontvangen. De inkomende kwaliteit wordt berekend door het totale aantal ontvangen pakketten en bytes te vergelijken met het totale aantal pakketten en bytes die door de peer worden verzonden.

Als LQM is ingeschakeld, worden de Link Quality Rapporten (LQR’s) elke houdbaarheidsperiode verzonden. LQR's worden verstuurd in plaats van keepaliven. Alle binnenkomende keepalives worden op de juiste manier beantwoord. Als LQM niet is geconfigureerd worden keepalives elke aanhoudende periode toegestuurd, en worden alle binnenkomende LQR's met een LQR beantwoord.

MagicNumber

De ondersteuning van het Magic Number is beschikbaar op alle seriële interfaces. PPP probeert altijd te onderhandelen over Magische Nummers, die worden gebruikt om netwerken met een loop-back-upnetwerk te detecteren. Een willekeurige reeks wordt over de link verzonden en als de zelfde waarde wordt teruggegeven, bepaalt de router dat de verbinding achteruit loopt.

De koppeling kan al dan niet worden opgeheven bij achteruitrijdetectie; het hangt af van het gebruik van de down-Wanneer-looped opdracht.

PAP (Wachtwoord-verificatieprotocol)

Dit bericht geeft aan dat het authenticatieprotocol dat wordt besproken voor gebruik door PPP peers PAP is. Raadpleeg voor meer informatie over PAP het PPP-protocol voor wachtwoordverificatie en de probleemoplossing van PPP-betalingen.

PFC (Protocol Field Compression)

Met deze optie wordt de compressie voor de protocolvelden in- of uitgeschakeld.

MRRU (Max. ontvanger gereconstrueerde eenheid)

Dit is een LCP-optie die tijdens het proces van PPP multilink LCP-instellingen is onderhandeld. Deze optie bepaalt het maximale aantal bytes dat een frame kan vormen. Als MRRU niet in LCP is onderhandeld, kan Multilink PPP (MPPP) niet op de link draaien.

MRU (maximaal ontvangen eenheid)

MRU is een LCP-optie die in het CONFREQ-kader is overeengekomen om te onderhandelen over de omvang van de uitgewisselde pakketten.

Verificatie

AUTH-REQ (verificatieaanvraag)

Dit kader wordt van de lokale PPP peer (waarop authenticatie is ingeschakeld) naar de afstandsbediening verstuurd. Het vraagt de externe peer om een geldige gebruikersnaam en wachtwoord voor PPP verbinding authenticatie te verzenden. Dit frame wordt alleen gebruikt met PAP.

AUTH-ACK (verificatiebevestiging)

Dit kader wordt uit de geauthentiseerde PPP peer naar de authenticerende PPP peer verzonden. Dit frame draagt de juiste gebruikersnaam en het juiste wachtwoord. Dit frame wordt alleen gebruikt wanneer PAP wordt gebruikt voor verificatie van PPP-verbindingen.

AUTH-NAK OF FOUT

Dit kader wordt uit het authenticerende PPP peer verzonden wanneer de authenticatie op de authenticatie PPP peer faalde.

UITDAGEN

Dit is het CHAP uitdaging frame dat van de authenticatie PPP peer naar de geauthentiseerde PPP peer wordt verzonden. Het uitdagingskader bestaat uit een ID, een willekeurig nummer en of de host naam van de lokale communicatieserver of de naam van de gebruiker op het externe apparaat. Dit kader wordt uitsluitend gebruikt wanneer CHAP voor PPP verbinding authenticatie wordt gebruikt.

REACTIE

Dit kader is de reactie van het KAP die van de geauthentiseerde PPP peer naar de authenticerende PPP peer wordt verzonden.

De vereiste reactie bestaat uit twee delen:

• Een MD5 hash-uitgang van het gedeelde geheim.

• Ofwel de hostnaam van het externe apparaat of de naam van de gebruiker op het externe apparaat.

Dit kader wordt uitsluitend gebruikt wanneer CHAP voor PPP verbinding authenticatie wordt gebruikt.

NCP

Adres a.b.c.d

• Op een uitgaand CONFREQ-bericht wijst deze waarde op het IP-adres dat de lokale router wenst te gebruiken. Als het inbegrepen adres 0.0.0.0 is, verzoekt de lokale machine de peer om het een IP adres te leveren dat het kan gebruiken.

• Op een inkomend CONFREQ bericht, wijst deze waarde op het IP adres dat de peer wil gebruiken. Als het inbegrepen adres 0.0.0.0 is, verzoekt de peer de lokale machine om het een IP adres te leveren dat het kan gebruiken.

• Op een uitgaand CONFNAK-bericht wijst deze waarde op het IP-adres dat de peer zou moeten gebruiken in plaats van het bericht dat de peer in het CONFREQ-bericht wordt voorgesteld.

• Op een inkomend CONFNAK-bericht wijst deze waarde op het IP-adres dat de lokale machine zou moeten gebruiken, in plaats van het bericht dat is voorgesteld in het vorige CONFREQ-bericht.

• Op een uitgaande CONFACK-bericht geeft deze waarde aan dat het IP-adres dat door de peer wordt gevraagd, acceptabel is voor de lokale machine.

• Op een inkomend CONFACK-bericht geeft deze waarde aan dat het IP-adres dat door de lokale machine is aangevraagd, acceptabel is voor de peer.

CCP (Compressie-Control Protocol)

Dit bericht geeft aan dat er tussen beide PPP-peers over een compressieprotocol wordt onderhandeld. Cisco IOS-software ondersteunt deze compressieprotocollen die via een PPP-verbinding worden onderhandeld:

• MS-point-to-point compressie (MS-PPC)

• stapelaar

• voorspeller

CDPCP (Cisco Discovery Protocol Control Protocol)

Dit bericht geeft aan dat CDP-onderhandeling plaatsvindt in de NCP-fase. Om CDP op de router uit te schakelen, geeft u de opdracht no cdp run uit.

CODEREJ (afwijzing van de code)

Een pakket CODEREJ wordt verzonden na ontvangst van een niet-interpreteerbaar ingepakt van de externe PPP-peer.

Installatie van de route naar b.c.d.

Wanneer de router IPCP (NCP fase voor IP L3 protocol) voltooit, moet het het bepaalde IP-adres aan de externe PPP-peer in de routingtabel installeren en gezien worden als een verbonden route in de routingtabel. Als u dit bericht niet ziet, controleer of het geen peer buurlijn-route opdracht is ingesteld.

IPCP (IP-controleprotocol)

Deze waarde wijst erop dat IP de netwerklaag is die in de NCP fase wordt onderhandeld.

IPCP-staat geopend

Dit bericht geeft aan dat de IPCP (NCP fase voor IP L3 protocol) is voltooid.

PROTREJ (Protocol afwijst)

De PPP peer, na ontvangst van een PPP pakket met een onbekend protocolveld gebruikt het PROTREJ bericht om aan te geven dat de peer heeft geprobeerd een protocol te gebruiken dat niet wordt ondersteund. Wanneer een PPP apparaat een PROTREJ bericht ontvangt, moet het bij de vroegste gelegenheid ophouden om pakketten van het aangegeven protocol te verzenden.

Gerelateerde informatie

• Configuratie- en probleemoplossing van PPP Password-verificatie Protocol (PAP)
• PPP-verificatie met behulp van de ppp chap hostname en ppp-verificatie ketting om opdrachten aan te roepen
• Het begrijpen en configureren van PPP CHAP-verificatie
• Problemen oplossen PPP (CHAP of PAP)-verificatie
• Ondersteuning van kiestechnologie
• Technische ondersteuning - Cisco-systemen