Questo diagramma di flusso consente di risolvere i problemi relativi al protocollo PPP (Point-to-Point Protocol), ampiamente utilizzato per più soluzioni tecnologiche di Access.
Nei diagrammi di flusso e nell'output di esempio mostrati di seguito, è stata configurata una connessione BRI (Basic Rate Interface) ISDN (Integrated Services Digital Network) PPP a un'altra connessione mediante il routing DDR (Dialer-on-Demand Routing) legacy. Tuttavia, le stesse procedure di risoluzione dei problemi si applicano alle connessioni ad altri router (ad esempio filiali) con connessioni PPP quando si utilizza Dialer Rotary-Group, Dialer Profile o PPP su collegamenti seriali.
Per ulteriori informazioni sul protocollo Point-to-Point e le sue funzionalità supportate nel software Cisco IOS®, fare riferimento a Cisco Learning Connection (solo utenti registrati) e cercare utilizzando la parola chiave ppp nel campo Search for training.
Per una spiegazione dettagliata delle diverse fasi della negoziazione PPP e dell'output della negoziazione PPP di debug, consultare il documento sulla configurazione e risoluzione dei problemi del protocollo PAP (PPP Password Authentication Protocol).
Verificare che siano soddisfatti i seguenti prerequisiti:
Abilitare la negoziazione ppp di debug e l'autenticazione ppp di debug.
È necessario leggere e comprendere l'output della negoziazione PPP di debug. Per ulteriori informazioni, fare riferimento a Informazioni sull'output del comando debug ppp negotiation.
La fase di autenticazione PPP non inizia finché la fase LCP (Link Control Protocol) non è completata ed è in stato "aperto". Se la negoziazione PPP di debug non indica che LCP è aperto, risolvere il problema prima di procedere.
Il documento può essere consultato per tutte le versioni software o hardware.
Computer locale (o router locale): Sistema su cui è in esecuzione la sessione di debug. Mentre si sposta la sessione di debug da un router all'altro, applicare il termine "computer locale" all'altro router.
Peer: L'altra estremità del collegamento point-to-point. Pertanto, il dispositivo non è il computer locale.
Ad esempio, se si esegue il comando debug ppp negotiation sul router A, questo è il computer locale e il router B è il peer. Tuttavia, se si sposta il debug su RouterB, questo diventa il computer locale e il routerA diventa il peer.
Nota: i termini computer locale e peer non implicano una relazione client-server. A seconda della posizione in cui viene eseguita la sessione di debug, il client di chiamata può essere il computer locale o un peer.
Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.
Questo documento include alcuni diagrammi di flusso per agevolare la risoluzione dei problemi.
Nota: per risolvere il problema, non ignorare i passaggi illustrati nei diagrammi di flusso.
Modem asincroni utilizzati per la connettività PPP
In questa sezione viene illustrato come utilizzare i modem asincroni per la connettività PPP. I frame LCP in uscita vengono visualizzati sul router locale, ma non sono presenti frame LCP in ingresso.
In questo caso, il problema potrebbe essere dovuto a una delle due possibilità seguenti:
I modem del router locale e del router remoto si collegano, ma il protocollo PPP non si avvia sul router remoto. Per risolvere questo problema, fare riferimento alla sezione Modem non addestrati correttamente, ma PPP non si avvia nel documento Risoluzione dei problemi relativi ai modem.
I modem dei router locali e remoti eseguono correttamente la preparazione e il PPP inizia su entrambi i router, ma la chiamata viene interrotta immediatamente. In questo modo viene eliminata qualsiasi possibilità di ricevere frame LCP in arrivo da router remoti. Per risolvere questo problema, fare riferimento alla sezione Modem di preparazione, PPP viene avviato, ma la chiamata viene interrotta in seguito nel documento Modem per la risoluzione dei problemi.
Per ulteriori informazioni sulla risoluzione dei problemi relativi ai modem, consultare il documento sulla risoluzione dei problemi dei modem.
Il diagramma seguente evidenzia alcuni dei parametri LCP PPP più comuni che possono essere negoziati durante la fase LCP. Questo diagramma di flusso consente di individuare i parametri LCP che il computer locale PPP non sta negoziando con il peer remoto PPP.
Il protocollo point-to-point offre una fase opzionale che garantisce all'utente della rete una trasmissione dei dati protetta per migliorare la sicurezza della rete. Su alcuni collegamenti può essere opportuno richiedere a un peer PPP di autenticarsi prima di consentire lo scambio dei pacchetti del protocollo a livello di rete. Per qualsiasi implementazione PPP, la fase di autenticazione è facoltativa per impostazione predefinita. Se un amministratore di rete PPP desidera che il peer PPP utilizzi un protocollo di autenticazione specifico, deve richiedere l'utilizzo di tale protocollo durante la fase PPP LCP. In altre parole, il protocollo di autenticazione utilizzato deve essere una delle opzioni LCP PPP negoziate tra entrambi i peer PPP.
In questa fase, solo i pacchetti PPP LCP, il protocollo di autenticazione e i pacchetti di monitoraggio della qualità del collegamento sono consentiti durante la fase di autenticazione. Prima di eseguire la procedura di risoluzione dei problemi descritta in questa sezione, verificare che non vi siano problemi con i parametri PPP negoziati con LCP.
Per informazioni dettagliate sulla risoluzione dei problemi relativi alla fase di autenticazione PPP, consultare il diagramma di flusso Risoluzione dei problemi di autenticazione PPP (CHAP o PAP).
Mentre i diversi NCP (Network Control Protocol) variano notevolmente nei dati negoziati, la struttura complessiva della conversazione è simile indipendentemente dai protocolli utilizzati. Questa sezione riguarda solo la negoziazione del protocollo IP (IPCP) NCP.
L'output seguente mostra l'output del comando debug per la riuscita della negoziazione IP durante la negoziazione PPP NCP:
As4 PPP: Phase is UP As4 IPCP: O CONFREQ [Not negotiated] id 1 len 10 As4 IPCP: Address 10.1.2.1 (0x03060A010201) As4 IPCP: I CONFREQ [REQsent] id 1 len 28 As4 IPCP: CompressType VJ 15 slots CompressSlotID (0x0206002D0F01) As4 IPCP: Address 0.0.0.0 (0x030600000000) As4 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000) As4 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000) As4 IPCP: O CONFREJ [REQsent] id 1 len 10 As4 IPCP: CompressType VJ 15 slots CompressSlotID (0x0206002D0F01) As4 CCP: I CONFREQ [Not negotiated] id 1 len 15 As4 CCP: MS-PPC supported bits 0x00000001 (0x120600000001) As4 CCP: Stacker history 1 check mode EXTENDED (0x1105000104) As4 LCP: O PROTREJ [Open] id 3 len 21 protocol CCP As4 LCP: (0x80FD0101000F12060000000111050001) As4 LCP: (0x04) As4 IPCP: I CONFACK [REQsent] id 1 len 10 As4 IPCP: Address 10.1.2.1 (0x03060A010201) %LINEPROTO-5-UPDOWN: Line protocol on Interface Async4, changed state to up As4 IPCP: I CONFREQ [ACKrcvd] id 2 len 22 As4 IPCP: Address 0.0.0.0 (0x030600000000) As4 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000) As4 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000) As4 IPCP: O CONFNAK [ACKrcvd] id 2 len 22 As4 IPCP: Address 10.1.2.2 (0x03060A010202) As4 IPCP: PrimaryDNS 10.2.2.3 (0x81060A020203) As4 IPCP: SecondaryDNS 10.2.3.1 (0x83060A020301) As4 IPCP: I CONFREQ [ACKrcvd] id 3 len 22 As4 IPCP: Address 10.1.2.2 (0x03060A010202) As4 IPCP: PrimaryDNS 10.2.2.3 (0x81060A020203) As4 IPCP: SecondaryDNS 10.2.3.1 (0x83060A020301) ip_get_pool: As4: validate address = 10.1.2.2 ip_get_pool: As4: using pool default ip_get_pool: As4: returning address = 10.1.2.2 set_ip_peer_addr: As4: address = 10.1.2.2 (3) is redundant As4 IPCP: O CONFACK [ACKrcvd] id 3 len 22 As4 IPCP: Address 10.1.2.2 (0x03060A010202) As4 IPCP: PrimaryDNS 10.2.2.3 (0x81060A020203) As4 IPCP: SecondaryDNS 10.2.3.1 (0x83060A020301) As4 IPCP: State is Open As4 IPCP: Install route to 10.1.2.2
Come indicato nel diagramma di flusso riportato di seguito, a questo punto il collegamento è attivo e sta passando un pacchetto, ma non si comporta correttamente.
L'output seguente mostra l'output del comando show caller user e show ip interface brief quando una chiamata viene terminata correttamente e i pacchetti IP possono essere inviati al peer remoto tramite la connessione PPP.
maui-soho-01#show caller user maui-soho-02 detail User: maui-soho-02, line BR0:1, service PPP Active time 00:02:21, Idle time 00:00:57 Timeouts: Absolute Idle Limits: - 00:02:00 Disconnect in: - 00:01:02 PPP: LCP Open, CHAP (local <--> local), IPCP LCP: -> peer, AuthProto, MagicNumber <- peer, AuthProto, MagicNumber NCP: Open IPCP IPCP: <- peer, Address -> peer, Address Dialer: Connected to #, inbound Idle timer 120 secs, idle 57 secs Type is ISDN, group BRI0 IP: Local 10.0.1.1/24, remote 10.0.1.2 Counts: 123 packets input, 3246 bytes, 0 no buffer 0 input errors, 0 CRC, 0 frame, 0 overrun 119 packets output, 2940 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets maui-soho-01#show ip interface brief Interface IP-Address OK? Method Status Protocol BRI0 10.0.1.1 YES NVRAM up up BRI0:1 unassigned YES unset up up BRI0:2 unassigned YES unset down down Ethernet0 172.22.53.160 YES NVRAM up up Serial0 unassigned YES NVRAM administratively down down
Revisione | Data di pubblicazione | Commenti |
---|---|---|
1.0 |
18-Dec-2007 |
Versione iniziale |