Un brin de réseau


Tel un cahier de notes, ce blog propose des articles sur les technologies réseaux et leur utilisation pratique, le tout illustré avec des maquettes et des captures.

#about #contact

PPPoE

Comme vu dans les articles sur PPP (première partie, deuxième partie), ce dernier a été conçu pour fonctionner sur des liens de nature point-à-point, liens pouvant être physiques (L1—par exemple, lien série classique ou lien série SONET/SDH) ou logiques (L2—par exemple, lien Frame Relay, ISDN ou ATM). Si les protocoles L2 cités en exemple ci-avant peuvent être configurés en point-à-point nativement, ce n'est pas le cas d'Ethernet qui est de nature multipoint. Aussi, PPP ne peut pas être encapsulé directement dans Ethernet et une couche d'adaptation intermédiaire, qui va simuler un lien L2 point-à-point (appelé « session »), doit être introduite. Cette couche, définie dans la RFC 2516, se nomme sans surprise PPPoE (PPP over Ethernet) et fonctionne en plusieurs étapes :

Étape Description Exemple pratique
PADI Le client PPPoE (appelé Host dans la RFC) recherche son pair, c'est-à-dire le serveur PPPoE (appelé Access Concentrator dans la RFC), via une trame broadcast. La box d'un abonné Internet recherche un BAS du FAI.
PADO Le ou les (pour des besoins de redondance) serveurs PPPoE présents sur le réseau Ethernet répondent au client PPPoE via une trame unicast. Le ou les BAS du FAI répondent à la box de l'abonné Internet.
PADR Le client PPPoE choisit un serveur PPPoE (critères de choix variables : celui qui a répondu le plus vite, selon le nom, etc.) et demande l'établissement de la session via une trame unicast. La box de l'abonné Internet choisit l'un des BAS du FAI.
PADS Le serveur PPPoE indique au client PPPoE que la session PPPoE est maintenant établie via une trame unicast (qui contient notamment le SESSION_ID). Le BAS choisi indique à la box de l'abonné Internet que la session PPPoE est maintenant établie.
À partir de là, le lien PPP peut être établi dans la session PPPoE (comme illustré dans l'article précédent). La box d'un abonné Internet émet et reçoit du trafic Internet.
PADT Enfin, une fois le lien PPP rompu, le client PPPoE ou le serveur PPPoE demande la fermeture de la session PPPoE. La box d'un abonné Internet vient d'être éteinte ou le lien physique entre la box et le FAI vient d'être rompu.

Noter que la RFC distingue deux phases : PPPoED (PPPoE Discovery) qui comprend les étapes un à quatre ainsi que la dernière (c'est-à-dire, l'établissement et la fermeture de la session PPPoE) et PPPoES (PPPoE Session) qui comprend l'étape cinq uniquement (c'est-à-dire, la session PPPoE proprement dite). Nous allons retrouver ces termes courants dans la capture réseau.

Voici une capture de PPPoE avec le lien PPP qui s'ensuit :

R1 (client PPPoE) R2 (serveur PPPoE)

            !
            hostname R1
            !
            username R2 password P
            !
            interface FastEthernet0/0
             pppoe enable
             pppoe-client dial-pool-number 2
            !
            interface Dialer1
             encapsulation ppp
             ppp authentication chap
             ip address 10.0.0.1 255.255.255.252
             dialer pool 2
             mtu 1492 # voir plus bas
             ip tcp adjust-mss 1452 # voir plus bas
            !
              

            !
            hostname R2
            !
            username R1 password P
            !
            bba-group pppoe global
             virtual-template 1
            !
            interface FastEthernet0/0
             pppoe enable group global
            !
            interface Virtual-Template1
             encapsulation ppp
             ppp authentication chap
             ip address 10.0.0.2 255.255.255.252
             mtu 1492 # voir plus bas
            !
              
cap-pppoe
Cette capture fait apparaître la phase PPPoED avec les étapes PADI, PADO, PADR et PADS qui ont permis d'établir la session PPPoE dans laquelle peut être établi le lien PPP. Nous retrouvons ainsi le même PPP que dans l'article précédent mais encapsulé sur Ethernet.

Nous pouvons voir les différentes sessions PPPoE établies sur le serveur PPPoE (une seule ici) via la commande suivante :


      R2#show pppoe session
           1 session  in LOCALLY_TERMINATED (PTA) State
           1 session  total

      Uniq ID  PPPoE  RemMAC          Port                  Source   VA         State
                 SID  LocMAC                                         VA-st
            1      1  c001.1b74.0000  Fa0/0                 Vt1      Vi1.1      PTA
                      c002.27f0.0000                                 UP
    

Nous pouvons aussi depuis le serveur PPPoE fermer la session PPPoE, ce qui permet de jouer les échanges liés à la fermeture :


      R2#clear pppoe rmac c001.1b74.0000
    
cap-pppoe-padt
En fermant la session PPPoE depuis le serveur PPPoE, ce dernier joue d'abord l'étape Terminate de PPP avant l'étape PADT de PPPoE.

La raison de la IP MTU (appelée PPP MRU) fixée à 1492 octets se comprend vite avec un schéma. Sur une transmission classique TCP/IP sur Ethernet (RFC 894), nous avons ceci :


        6 octets   6 octets   2 octets   20 octets   20  octets   1460 octets   4 octets
      +----------+----------+----------+-----------+------------+-------------+----------+
      |    DA    |    SA    | Len/Type | IP Header | TCP Header |  TCP  Data  |   FCS    |
      +----------+----------+----------+-----------+------------+-------------+----------+
                                       <------------ 1500  octets ------------>
    

Or, sur une transmission TCP/IP sur PPPoE, huit octets de plus doivent être intégrés à la trame Ethernet sans pour autant agrandir sa taille :


        6 octets   6 octets   2 octets   6 octets   2 octets   20 octets   20  octets   1452 octets   4 octets
      +----------+----------+----------+----------+----------+-----------+------------+-------------+----------+
      |    DA    |    SA    | Len/Type |  PPPoES  |   PPP    | IP Header | TCP Header |  TCP  Data  |   FCS    |
      +----------+----------+----------+----------+----------+-----------+------------+-------------+----------+
                                                             <------------ 1492  octets ------------>
                                       <----------------------- 1500  octets ----------------------->
    

Ces huit octets sont alors impactés sur la taille de la IP MTU ainsi que la taille de la TCP MSS. Noter que le client PPPoE (typiquement, une box d'un abonné Internet) n'émet pas de segment TCP—ou alors, lorsqu'elle est supervisée à distance. C'est surtout l'équipement de l'utilisateur final (typiquement, un ordinateur fixe ou portable) qui en émet dans le cadre de son trafic Internet. La commande liée à la TCP MSS permet de modifier « à la volée » celle annoncée par l'équipement de l'utilisateur final (dans les segments SYN) qui reste, elle, configurée à 1460 octets par défaut.

Pourquoi PPPoEoVLAN ?

Cette appellation signifie juste qu'il y a un VLAN présent dans les trames Ethernet encapsulant PPPoE. La motivation est celle même des VLAN : en segmentant le domaine de diffusion L2, ils apportent sécurité et performance. Dans un contexte PPPoE, prenons l'exemple d'un opérateur qui agrège sur un même switch Ethernet le trafic de ses clients professionnels et résidentiels. À l'évidence, séparer leur trafic avec des VLAN distincts est une bonne pratique.

Pourquoi PPPoEoA ?

Cette appellation signifie que la trame Ethernet encapsulant PPPoE est transportée dans ATM. Ce n'est pas PPPoE seul qui est transporté mais bien la trame Ethernet entière. De plus, ce n'est pas un protocole à proprement parler mais une méthode d'encapsulation décrite dans la RFC 2684 qui ne concerne pas qu'Ethernet mais aussi IP par exemple (précurseur de MPLS).