François Goffinet

François Goffinet

4 volumes CCNA en format PDF Mobi Epub

Objectifs de certification

CCNA R&S 200-125

  • 4.1 Configurer et vérifier PPP et MLPPP sur des interfaces WAN en utilisant une authentification locale

  • 4.2 Configurer, vérifier et dépanner des interfaces PPPoE côté client qui utilisent une authentification locale

  • 4.5 Décrire les options de connectivité d’accès WAN (MPLS, Metro Ethernet, Broadband PPPoE, Internet VPN DMVPN, site-to-site VPN, client VPN)

  • 4.2 Configurer, vérifier et dépanner des interfaces PPPoE côté client qui utilisent une authentification locale

  • 4.5 Décrire les options de connectivité d’accès WAN (MPLS, Metro Ethernet, Broadband PPPoE, Internet VPN DMVPN, site-to-site VPN, client VPN)

PPP, MLPPP et PPPoE

1. Lignes louées avec PPP

Point-to-Point Protocol (PPP, protocole point à point) est un protocole de transport pour l’Internet, décrit par le standard RFC 1661, fortement basé sur HDLC, qui permet d’établir une connexion entre deux hôtes sur une liaison point à point. Il fait partie de la couche liaison de données (couche 2) du modèle OSI.

Les fonctionnalités d’authentification est assurée par les protocoles PAP ou CHAP. Il est capable d’agréger les liaisons grâce à PPP Multilink (MLPPP). Enfin, il permet de créer des connexions point à point par sur-encapsulation sur une technologie partagée comme Ethernet (PPPoE).

1.1. Concepts PPP

PPP s’appuie sur trois composants :

  • L’encapsulation des datagrammes.
  • Le contrôle de la liaison avec LCP (Link Control Protocol).
  • Le contrôle de la couche réseau avec NCP (Network Control Protocol).

Le protocole PPP permet une meilleure gestion des liaisons par rapport à HDLC car :

  • Il prend en charge des mécanismes d’authentification, comme PAP ou CHAP.
  • Il permet l’agrégation de lien (on parle de PPP Multilink).
  • Il permet la compression des données

Source (adaptée) : https://fr.wikipedia.org/wiki/Point-to-Point_Protocol

1.2. Tramage HDLC/PPP

Trame HDLC

Frame 3: 104 bytes on wire (832 bits), 104 bytes captured (832 bits) on interface 0
Cisco HDLC
    Address: Unicast (0x0f)
    Control: 0x00
    Protocol: IP (0x0800)
Internet Protocol Version 4, Src: 11.1.2.2, Dst: 11.1.3.2
Internet Control Message Protocol

Source : https://www.cloudshark.org/captures/6255ac5699a2

Trames PPP

Frame 112: 104 bytes on wire (832 bits), 104 bytes captured (832 bits) on interface 0
Point-to-Point Protocol
    Address: 0xff
    Control: 0x03
    Protocol: Internet Protocol version 4 (0x0021)
Internet Protocol Version 4, Src: 11.1.2.2, Dst: 11.1.3.2
Internet Control Message Protocol

Source : https://www.cloudshark.org/captures/d31c4bd21ebc

1.3. Protocoles de contrôle PPP

*Mar  1 00:14:02.471: %LINK-5-CHANGED: Interface Serial0/0, changed state to administratively down
R3(config-if)#
*Mar  1 00:14:02.475: Se0/0 PPP: Sending Acct Event[Down] id[3]
*Mar  1 00:14:02.479: Se0/0 CDPCP: State is Closed
*Mar  1 00:14:02.479: Se0/0 IPCP: State is Closed
*Mar  1 00:14:02.483: Se0/0 PPP: Phase is TERMINATING
*Mar  1 00:14:02.483: Se0/0 LCP: State is Closed
*Mar  1 00:14:02.483: Se0/0 PPP: Phase is DOWN
*Mar  1 00:14:02.487: Se0/0 IPCP: Remove route to 11.1.3.1
*Mar  1 00:14:03.471: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, changed state to down

1.4. LCP

Le sous-protocle LCP (Link Control Protocol) ne s’occupe que paramètres de couche 2 :

  • Détection de boucle : transmission d’un nombre magique
  • Détection d’erreur avec LQM Link-Quality Monitoring
  • Support Multilink : répartion de charge sur plusieurs liaisons
  • Authentication : PAP ou CHAP

1.5. NCP

Network Control Protocols (NCP) est une catégorie de protocole qui négocie des paramètres de couche 3 pour son propre compte comme par exemple :

  • CDPCP
  • IPCP

1.6. Authentification PPP PAP

Password Authentication Protocol (PAP) est un protocole d’authentification pour PPP. Les données d’authentification sont transmises en texte clair sur le réseau ce qui le rend par conséquent non sécurisé.

L’avantage du PAP est qu’il est extrêmement simple à implémenter, lui permettant d’être utilisé dans des systèmes embarqués très légers. Sur des systèmes de taille raisonnable on préférera sans doute le protocole CHAP.

Source : https://fr.wikipedia.org/wiki/Password_Authentication_Protocol

1.7. Authentification PPP CHAP

Challenge Handshake Authentication Protocol (CHAP) est un protocole d’authentification pour PPP à base de challenge, ce qui le rend bien plus sûr que son pendant PAP. Ce protocole est défini dans la RFC 1994. Il est aussi utilisé par le protocole iSCSI afin qu’Initiator et Target iSCSI s’authentifient éventuellement mutuellement.

L’objectif de CHAP est que le pair s’authentifie auprès d’un authentificateur sans échange de mot de passe en clair sur le réseau et sans que l’échange puisse être rejoué par un tiers à l’écoute. La contrainte est que chaque partie partage un “secret” (mot de passe) commun. Microsoft a développé la variante MS-CHAP qui supprime cette contrainte.

Dès le début de la connexion, CHAP réclame la preuve de l’identité du correspondant, en lui demandant de chiffrer une information, le défi (“challenge”). Le correspondant ne peut relever le défi que s’il possède effectivement la clé unique et secrète, le “secret”, qu’ils partagent (ceci peut être un mot de passe).

Voici les différentes étapes de la procédure d’authentification CHAP :

  1. Après l’établissement de la connexion, l’authentificateur envoie le défi au pair. C’est une valeur d’au plus 255 octets générée aléatoirement ce qui lui confère le caractère non rejouable.
  2. Le pair répond avec une valeur calculée sur la base du défi et du “secret” en utilisant une fonction de hachage à sens unique, telle que MD5. Concrètement il concatène le secret et le défi et calcule l’identifiant (par exemple MD5) de l’ensemble. Il envoie la réponse à l’authentificateur.
  3. L’authentificateur effectue la même opération (ce qui nécessite la connaissance du secret) et compare avec le résultat reçu. Il accepte ou refuse la connexion en le notifiant au pair.
  4. À intervalle régulier, CHAP renvoie un nouveau défi au pair.
*Mar  1 00:17:56.467: %LINK-3-UPDOWN: Interface Serial0/0, changed state to up
*Mar  1 00:17:56.471: Se0/0 PPP: Using default call direction
*Mar  1 00:17:56.475: Se0/0 PPP: Treating connection as a dedicated line
*Mar  1 00:17:56.475: Se0/0 PPP: Session handle[F6000004] Session id[5]
*Mar  1 00:17:56.475: Se0/0 PPP: Authorization required
*Mar  1 00:17:56.507: Se0/0 CHAP: O CHALLENGE id 3 len 23 from "R3"
*Mar  1 00:17:56.527: Se0/0 CHAP: I CHALLENGE id 4 len 23 from "R1"
*Mar  1 00:17:56.535: Se0/0 CHAP: Using hostname from unknown source
*Mar  1 00:17:56.535: Se0/0 CHAP: Using password from AAA
*Mar  1 00:17:56.535: Se0/0 CHAP: O RESPONSE id 4 len 23 from "R3"
*Mar  1 00:17:56.535: Se0/0 CHAP: I RESPONSE id 3 len 23 from "R1"
*Mar  1 00:17:56.543: Se0/0 PPP: Sent CHAP LOGIN Request
*Mar  1 00:17:56.543: Se0/0 PPP: Received LOGIN Response PASS
*Mar  1 00:17:56.547: Se0/0 PPP: Sent LCP AUTHOR Request
*Mar  1 00:17:56.547: Se0/0 PPP: Sent IPCP AUTHOR Request
*Mar  1 00:17:56.551: Se0/0 CHAP: I SUCCESS id 4 len 4
*Mar  1 00:17:56.551: Se0/0 LCP: Received AAA AUTHOR Response PASS
*Mar  1 00:17:56.555: Se0/0 IPCP: Received AAA AUTHOR Response PASS
*Mar  1 00:17:56.555: Se0/0 CHAP: O SUCCESS id 3 len 4
*Mar  1 00:17:56.559: Se0/0 PPP: Sent CDPCP AUTHOR Request
*Mar  1 00:17:56.559: Se0/0 PPP: Sent IPCP AUTHOR Request
*Mar  1 00:17:56.563: Se0/0 CDPCP: Received AAA AUTHOR Response PASS
*Mar  1 00:17:57.555: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, changed state to up

1.8. Procédure PPP

*Mar  1 00:14:16.271: Se0/0 PPP: Outbound cdp packet dropped
*Mar  1 00:14:18.263: %LINK-3-UPDOWN: Interface Serial0/0, changed state to up
*Mar  1 00:14:18.267: Se0/0 PPP: Using default call direction
*Mar  1 00:14:18.271: Se0/0 PPP: Treating connection as a dedicated line
*Mar  1 00:14:18.271: Se0/0 PPP: Session handle[4C000003] Session id[4]
*Mar  1 00:14:18.271: Se0/0 PPP: Phase is ESTABLISHING, Active Open
*Mar  1 00:14:18.271: Se0/0 LCP: O CONFREQ [Closed] id 4 len 15
*Mar  1 00:14:18.275: Se0/0 LCP:    AuthProto CHAP (0x0305C22305)
*Mar  1 00:14:18.275: Se0/0 LCP:    MagicNumber 0x0155D6D8 (0x05060155D6D8)
*Mar  1 00:14:18.287: Se0/0 LCP: I CONFREQ [REQsent] id 6 len 15
*Mar  1 00:14:18.287: Se0/0 LCP:    AuthProto CHAP (0x0305C22305)
*Mar  1 00:14:18.287: Se0/0 LCP:    MagicNumber 0x0255E5CA (0x05060255E5CA)
*Mar  1 00:14:18.291: Se0/0 LCP: O CONFACK [REQsent] id 6 len 15
*Mar  1 00:14:18.291: Se0/0 LCP:    AuthProto CHAP (0x0305C22305)
*Mar  1 00:14:18.291: Se0/0 LCP:    MagicNumber 0x0255E5CA (0x05060255E5CA)
*Mar  1 00:14:18.295: Se0/0 LCP: I CONFACK [ACKsent] id 4 len 15
*Mar  1 00:14:18.295: Se0/0 LCP:    AuthProto CHAP (0x0305C22305)
*Mar  1 00:14:18.295: Se0/0 LCP:    MagicNumber 0x0155D6D8 (0x05060155D6D8)
*Mar  1 00:14:18.295: Se0/0 LCP: State is Open
*Mar  1 00:14:18.299: Se0/0 PPP: Phase is AUTHENTICATING, by both
*Mar  1 00:14:18.299: Se0/0 CHAP: O CHALLENGE id 2 len 23 from "R3"
*Mar  1 00:14:18.315: Se0/0 CHAP: I CHALLENGE id 3 len 23 from "R1"
*Mar  1 00:14:18.327: Se0/0 CHAP: Using hostname from unknown source
*Mar  1 00:14:18.327: Se0/0 CHAP: Using password from AAA
*Mar  1 00:14:18.327: Se0/0 CHAP: O RESPONSE id 3 len 23 from "R3"
*Mar  1 00:14:18.327: Se0/0 CHAP: I RESPONSE id 2 len 23 from "R1"
*Mar  1 00:14:18.327: Se0/0 PPP: Phase is FORWARDING, Attempting Forward
*Mar  1 00:14:18.327: Se0/0 PPP: Phase is AUTHENTICATING, Unauthenticated User
*Mar  1 00:14:18.331: Se0/0 PPP: Phase is FORWARDING, Attempting Forward
*Mar  1 00:14:18.331: Se0/0 PPP: Phase is AUTHENTICATING, Authenticated User
*Mar  1 00:14:18.339: Se0/0 CHAP: I SUCCESS id 3 len 4
*Mar  1 00:14:18.339: Se0/0 CHAP: O SUCCESS id 2 len 4
*Mar  1 00:14:18.343: Se0/0 PPP: Phase is UP
*Mar  1 00:14:18.343: Se0/0 IPCP: O CONFREQ [Closed] id 1 len 10
*Mar  1 00:14:18.343: Se0/0 IPCP:    Address 11.1.3.2 (0x03060B010302)
*Mar  1 00:14:18.343: Se0/0 PPP: Process pending ncp packets
*Mar  1 00:14:18.347: Se0/0 IPCP: I CONFREQ [REQsent] id 1 len 10
*Mar  1 00:14:18.347: Se0/0 IPCP:    Address 11.1.3.1 (0x03060B010301)
*Mar  1 00:14:18.347: Se0/0 AAA/AUTHOR/IPCP: Start.  Her address 11.1.3.1, we want 0.0.0.0
*Mar  1 00:14:18.351: Se0/0 CDPCP: I CONFREQ [Closed] id 1 len 4
*Mar  1 00:14:18.351: Se0/0 AAA/AUTHOR/IPCP: Reject 11.1.3.1, using 0.0.0.0
*Mar  1 00:14:18.351: Se0/0 AAA/AUTHOR/IPCP: Done.  Her address 11.1.3.1, we want 0.0.0.0
*Mar  1 00:14:18.351: Se0/0 IPCP: O CONFACK [REQsent] id 1 len 10
*Mar  1 00:14:18.351: Se0/0 IPCP:    Address 11.1.3.1 (0x03060B010301)
*Mar  1 00:14:18.351: Se0/0 IPCP: I CONFACK [ACKsent] id 1 len 10
*Mar  1 00:14:18.351: Se0/0 IPCP:    Address 11.1.3.2 (0x03060B010302)
*Mar  1 00:14:18.351: Se0/0 IPCP: State is Open
*Mar  1 00:14:18.355: Se0/0 CDPCP: O CONFREQ [Closed] id 1 len 4
*Mar  1 00:14:18.363: Se0/0 IPCP: Install route to 11.1.3.1
*Mar  1 00:14:18.363: Se0/0 CDPCP: I CONFACK [REQsent] id 1 len 4
*Mar  1 00:14:19.343: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, changed state to up
*Mar  1 00:14:20.355: Se0/0 CDPCP: Timeout: State ACKrcvd
*Mar  1 00:14:20.355: Se0/0 CDPCP: O CONFREQ [ACKrcvd] id 2 len 4
*Mar  1 00:14:20.371: Se0/0 CDPCP: I CONFACK [REQsent] id 2 len 4
*Mar  1 00:14:20.375: Se0/0 CDPCP: I CONFREQ [ACKrcvd] id 2 len 4
*Mar  1 00:14:20.375: Se0/0 CDPCP: O CONFACK [ACKrcvd] id 2 len 4
*Mar  1 00:14:20.375: Se0/0 CDPCP: State is Open

1.9. Capture de trafic PPP CHAP

https://www.cloudshark.org/captures/d31c4bd21ebc

2. Configurer et vérifier PPP

2.1. Configurer PPP

(config)#interface s0/0
(config-if)#encapsulation ppp

2.2. Conectivité locale (R3 S0/0)

Vérification du statut de l’interface et de l’encapsulation :

R3#show interfaces s0/0
Serial0/0 is up, line protocol is up
  Hardware is GT96K Serial
  Internet address is 11.1.3.2/24
  MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation HDLC, loopback not set
  Keepalive set (10 sec)
  CRC checking enabled
...

Serial0/0 is up, line protocol is up et Encapsulation HDLC.

Couche physique :

R3#show controllers s0/0
Interface Serial0/0
Hardware is GT96K
DCE 530, clock rate 2000000
idb at 0x665D7118, driver data structure at 0x665DE824
...

DCE 530, clock rate 2000000

Etat de l’interface :

R3#show ip interface brief | include Serial0/0
Serial0/0                  11.1.3.2        YES manual up                    up

Si CDP répond, la couche 2 est opérationnelle sur la liaison :

R3#show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater

Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
R1               Ser 0/0            133         R S I     3725      Ser 0/0
R3#

2.3. Configurer PPP CHAP

Topologie PPP CHAP

Activation de PPP CHAP entre R1 et R3.

R1(config)#username R3 password testtest
R1(config)#int s0/0
R1(config-if)#encapsulation ppp
R1(config-if)#ppp authentication chap

R3(config)#username R1 password testtest
R3(config)#int s0/0
R3(config-if)#encapsulation ppp
R3(config-if)#ppp authentication chap

2.4. Diagnostic PPP

#show interface s0/0
#show controllers s0/0
#debug ppp authentication
#debug ppp negotiation

3. MLPPP

MLPPP (PPP Multilink) est la variante du protocole PPP qui permet d’agréger des liaisons physiques pour créer un seul canal logique. Le protocole permet de répartir la charge sur les liaisons cumulées et offre un certain niveau de redondance en cas de rupture d’une des liaisons physiques.

Topologie PPPoE

Dans ce scénario, on ajoute une interface S0/0 et une interface S0/1 au groupe ppp multilink 1.

3.1. Configuration MLPPP

R1(config)#int s0/0
R1(config-if)#no ip address
R1(config-if)#encapsulation ppp
R1(config-if)#ppp multilink
R1(config-if)#ppp multilink group 1
R1(config-if)#int s0/1
R1(config-if)#encapsulation ppp
R1(config-if)#ppp authentication chap
R1(config-if)#ppp multilink
R1(config-if)#ppp multilink group 1
R1(config-if)#no shutdown
R1(config-if)#int multi 1
R1(config-if)#encapsulation ppp
R1(config-if)#ppp multilink
R1(config-if)#ppp multilink group 1
R1(config-if)#ip add 11.1.3.1 255.255.255.0
R1(config-if)#exit

R3(config)#int s0/0
R3(config-if)#no ip address
R3(config-if)#encapsulation ppp
R3(config-if)#ppp multilink
R3(config-if)#ppp multilink group 1
R3(config-if)#ip nat outside
R3(config-if)#int s0/1
R3(config-if)#encapsulation ppp
R3(config-if)#ppp authentication chap
R3(config-if)#ppp multilink
R3(config-if)#ppp multilink group 1
R3(config-if)#no shutdown
R3(config-if)#int multi 1
R3(config-if)#encapsulation ppp
R3(config-if)#ppp multilink
R3(config-if)#ppp multilink group 1
R3(config-if)#ip add 11.1.3.2 255.255.255.0
R3(config-if)#ip nat outside
R3(config-if)#exit
R3(config)#no ip nat inside source list LAN interface Serial0/0 overload
R3(config)#ip nat inside source list LAN interface multi 1 overload

3.2. Diagnostic MLPPP

R3#show ppp multilink interface multilink 1

Multilink1
  Bundle name: R1
  Remote Username: R1
  Remote Endpoint Discriminator: [1] R1
  Local Username: R3
  Local Endpoint Discriminator: [1] R3
  Bundle up for 02:37:42, total bandwidth 3088, load 1/255
  Receive buffer limit 24000 bytes, frag timeout 1000 ms
    0/0 fragments/bytes in reassembly list
    0 lost fragments, 0 reordered
    0/0 discarded fragments/bytes, 0 lost received
    0x13B received sequence, 0x13D sent sequence
  Member links: 2 active, 0 inactive (max not set, min not set)
    Se0/0, since 02:37:43
    Se0/1, since 02:37:40

R3#show interfaces multilink 1
Multilink1 is up, line protocol is up
  Hardware is multilink group interface
  Internet address is 11.1.3.2/24
  MTU 1500 bytes, BW 3088 Kbit/sec, DLY 100000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation PPP, LCP Open, multilink Open
  Open: IPCP, CDPCP, loopback not set
  Keepalive set (10 sec)
  DTR is pulsed for 2 seconds on reset
  Last input 00:00:20, output never, output hang never
  Last clearing of "show interface" counters 02:38:04
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     164 packets input, 53152 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
     165 packets output, 54936 bytes, 0 underruns
     0 output errors, 0 collisions, 1 interface resets
     0 unknown protocol drops
     0 output buffer failures, 0 output buffers swapped out

Où BW 3088 Kbit/sec

4. PPP over Ethernet (PPPoE)

4.1. PPPoE

PPPoE fournit une méthode standard pour l’emploi des méthodes d’authentification du protocole point à point (PPP) sur un réseau Ethernet. Lorsqu’il est utilisé par les FAI (fournisseur d’accès internet), PPPoE permet l’attribution authentifiée des adresses IP. Dans ce type d’implémentation, le client et le serveur PPPoE sont interconnectés par des protocoles de couche 2 fonctionnant sur une connexion DSL ou à large bande.

Le PPPoE se compose de deux phases principales :

  • Phase de découverte active (Active Discovery Phase) : Dans cette phase, le client PPPoE localise un serveur PPPoE, appelé concentrateur d’accès. Pendant cette phase, un ID de session est attribué et la couche PPPoE est établie.
  • Phase de session PPP (PPP Session Phase) : Dans cette phase, les options PPP sont négociées et l’authentification est effectuée. Une fois la configuration de la liaison terminée, PPPoE fonctionne comme une méthode d’encapsulation de couche 2, permettant le transfert des données sur la liaison PPP dans les en-têtes PPPoE.

Source : PPPoE Client

4.2. Configurer PPP over Ethernet

  1. Authentication avec Chap/Pap (Username: client1, password: testtest)
  2. Le client est authentifié par le serveur (one way)
  3. L’adresse IP est négociée via IPCP
Topolgie PPPoE
  • R1 est serveur PPPoE.
  • R2 est client PPPoE
  • Username : client1
  • Password : testtest

Explication :

  • PPPoE Active Discovery Initiation (PADI) – A packet that is sent with the destination_addr set to the Broadcast address. The packet indicates the type of service requested.
  • PPPoE Active Discovery Offer (PADO) – A packet that is sent with the destination_addr set to the unicast address of the PPPoE client. The packet contains an offer for the client
  • PPPoE Active Discovery Request (PADR) – A packet that is sent from the PPPoE client with the destination_addr set to the chosen access concentrator. The packet contains a session request from the client
  • PPPoE Active Discovery Session-Confirmation (PADS) – A packet that is sent as confirmation to the client. The packet contains the unique PPPoE session ID
  • PPPoE Active Discovery Termination (PADT) – A packet that is sent to terminate the PPPoE session.

Configuration Client R2 :

Il est nécessaire d’adapter la configuration NAT

interface G0/1
 no ip address
 no shutdown
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip tcp adjust-mss 1452
 pppoe enable
 pppoe-client dial-pool-number 1
 no ip nat outside
!
interface Dialer1
 ip address negotiated
 encapsulation ppp
 dialer pool 1
 dialer-group 1
 no cdp enable
 ppp authentication pap chap callin
 ppp pap sent-username client1 password testtest
 ppp chap hostname client1
 ppp chap password testtest
 ip nat outside
!
no ip nat inside source list LAN interface GigabitEthernet0/1 overload
ip nat inside source list LAN interface Dialer1 overload

Configuration Serveur :

username client1 secret testtest
!
bba-group pppoe global
virtual-template 1
!
interface F0/0
 load-interval 30
 pppoe enable group global
 ip add 11.1.2.1 255.255.255.0
 no shutdown
!
interface Virtual-Template1
 mtu 1492
 ip unnumbered F0/0
 peer default ip address pool pppoepool
 ppp authentication pap chap
!
ip local pool pppoepool 11.1.2.100 11.1.2.109

4.3. Diagnostic

R2#show interfaces dialer 1
Dialer1 is up, line protocol is up (spoofing)
  Hardware is Unknown
  Internet address is 10.1.2.100/32
  MTU 1500 bytes, BW 56 Kbit/sec, DLY 20000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation PPP, LCP Closed, loopback not set
  Keepalive set (10 sec)
  DTR is pulsed for 1 seconds on reset
  Interface is bound to Vi2
...

R2#show ip interface dialer 1
Dialer1 is up, line protocol is up
  Internet address is 10.1.2.100/32
  Broadcast address is 255.255.255.255
  Address determined by IPCP
  MTU is 1500 bytes
...

Étapes de montage de la liaison :

  1. Le client négocie PPPoE en utilisant PADo, PADi et PADr avec le serveur et puis les deux, client et serveur, entrent dans la phase LCP.
  2. Client et serveur négocient les paramètres d’authentification et d’autres.
  3. Le serveur demande au client son “username/password”.
  4. Le client envoie son couple “username/password” configuré dans son “Dialer”.
  5. Le serveur authentifie ce couple “username/password” contre sa base de données d’utilisateurs locaux (ou via un serveur AAA/Radius)
  6. Client et serveur entrent en phase IPCP.
  7. Le client envoie une adresse IP 0.0.0.0 demandant une adresse IP au serveur.
  8. Le serveur fournit une adresse IP puisée dans son “pppoepool”
  9. Client et serveur terminent la phase IPCP et le lien est monté.
#debug ppp negotiation

Capture du trafic :

https://www.cloudshark.org/captures/07b9bbcbfdc3

Vous pourriez aimer aussi