Auteur Sujet: Le combat PPPoA PPPoE IPoA IPoE  (Lu 55969 fois)

0 Membres et 1 Invité sur ce sujet

vivien

  • Administrateur
  • *
  • Messages: 47 079
    • Twitter LaFibre.info
Le combat PPPoA PPPoE IPoA IPoE
« le: 24 mai 2011 à 07:27:26 »
Le retour du combat de PPPoA / PPPoE vs IPoA / IPoE

Certains s'étonnent que des abonnements à fibre optique utilisent le PPPoE (ou le PPPoA) par exemple l'offre fibre d'Orange [édit : ce n'est plus le cas aujourd'hui].

François Contat fait le point entre l'IPoX (l'attribution d'IP serait directement via un client DHCP, ce qui permet de connecter le média-converter / ou l'ONT directement au PC sans faire de configuration) et le PPPoX qui nécessite un login / password pour établir la connexion.


Les avantages du PPPoX :

  • L'avantage de ce protocole est qu'il est lié à Radius, donc on a un nombre important d'informations sur l'utilisateur à l'instant T : On sait (si on a un accounting cohérent et un système de requêtage intelligent) si un client est connecté, le moment de sa dernière coupure (que ce soit à l'initiative de l'abonné ou celle de l'équipement de collecte). On peut faire des stats de trafic sur les tickets d'acct stop, dégager des comportements utilisateurs, etc.

  • La gestion de déménagement d'abonné n'implique pas de changer des informations d'authentification : dans le cas du ppp, il s'agit du login qui fera foi, tandis qu'en DHCP, ce sera l'option 82 qui est lié à l'interface physique du DSLAM, OLT, ou autre qui fera foi. Donc en cas de déménagement, il faut aussi prendre en compte la nouvelle option 82. En cas de déplacement de port, etc. la gestion via PPP est beaucoup plus flexible.

  • Le tunneling L2TP qui permet de très facilement concentrer la collecte de certains clients (B2B) sur des LNS dédiés ou autre.


Les inconvénients du PPPoX :

  • En PPPoE : La fragmentation liée à la MTU de 1492

  • Le coût du PPP existe (on l'oublie souvent), car il faut bien collecter les clients pour leur assigner une ip (et un subnet dans le cas d'offre B2B). Il y a donc un coût financier en équipement, maintenance, humain pour gérer ces équipements, dalles, etc. Bref, ce n'est pas un coût si anodin.

  • La QoS qui est anecdotique sur le PPP. On en parle depuis longtemps, mais je n'ai jamais vu un équipement de type LNS faire de la QoS qui marche ou qui lorsqu'elle fonctionne n'écroule pas les performances de la machine (on en revient au coût).




Les avantages de l'IPoX :

  • QoS. La QoS est fonctionnelle, éprouvée et fonctionne chez TOUS les constructeurs d'équipement de collecte de ligne (DSLAM, OLT, etc.), du moins ceux auxquels j'ai pu toucher. Il n'y a rien de sorcier pour la mettre en place contrairement à l'expérimentation PPPoX qui est particulièrement lourde et qui ne fonctionne pas.

  • Le coût. Là où on a des équipements de collecte (BAS, LNS), ici, nous n'avons plus rien, juste un switch qui fera relay DHCP. Là où l'on avait des radiusd, on remplace par des dhcpd. La différence de coût est grosse.

  • Le coût au niveau IAD. Côté client, je pense (jamais mené de test à ce propos, mais la logique le veut) que les performances de l'équipement s'en ressentent : une encapsulation / décapsulation en moins. Et dans le cas de petits paquets arrivant à un débit important, les performances du modem peuvent s'en trouver TRÈS affecté. J'ai mené des stress test sur un certain nombre d'équipementiers modem et il est très facile de tuer un modem avec un "bon" débit en upstream et des paquets bien dimensionnés ⇒ le CPU de ce dernier atteint très vite les 100% CPU


Les inconvénients de l'IPoX :

  • Aucune notion de fin de session. On n'a aucune information sur l'utilisateur et son état et ne récupérons pas d'informations sur sa connexion contrairement au Radius. Ce point peut sembler anodin, il n'en est rien. Une hotline a besoin de savoir à l'instant X si un client est connecté (et non ping n'est pas une réponse) : Un port de DSLAM peut être marqué up mais ce n'est pas pour autant que le client fonctionne. On a déjà vu des cartes de DSLAM en carafe qui refusent de laisser passer un paquet tout en restant up. Le ping n'est pas une solution, car un certain nombre de personnes bloquent le ping. Ce point de notion de session est le plus sensible à mon sens. Pour avoir une info de début de session en DHCP, il suffit d'avoir un parser de log afin d'avoir ces informations. Le point négatif du DHCP est qu'il n'y a pas d'ACCT STOP.

corrector

  • Invité
Le combat PPPoA PPPoE IPoA IPoE
« Réponse #1 le: 24 mai 2011 à 18:30:18 »
Concernant l'encapsulation

Pour ma part, je considère que tous ces protocoles sont surtout des distractions, de la complexité inutile et une perte de temps et de bande passante.

Concernant le fait de mettre de l'IP dans de l'ATM

Je ne vois pas à quoi ça peut bien servir à part rajouter un en-tête ridiculement grand (en proportion de la charge utile ATM).

Je ne vois pas où il est dit que le DSL doit transporter de l'ATM.

Je ne peux imaginer aucun cas où, ayant le choix, il serait préférable d'utiliser ATM pour transporter de l'IP.

Concernant la centralisation des BAS/LNS

Cela enlève toute possibilité d'exploiter la multidiffusion sur le réseau de collecte : pour envoyer un paquet à n clients, il faut l'envoyer individuellement dans n tunnels PPP, même si les tunnels passent par le même lien qui permet la multidiffusion.

corrector

  • Invité
QoS sur PPP
« Réponse #2 le: 03 juin 2011 à 16:52:03 »
  • La QoS qui est anecdotique sur le PPP. On en parle depuis longtemps mais je n'ai jamais vu un équipement de type LNS faire de la QoS qui marche ou qui lorsqu'elle fonctionne n'écroule pas les performances de la machine (on en revient au coût).
Demande à Free!

Free a longtemps appliqué aux IP/ADSL un étranglement des flux non Web aux heures de pointe. Et même une discrimination sur le user-agent.

C'est une non-qualité de service, mais je pense que les mêmes outils bien réglés permettent aussi d'assurer une bonne qualité de service.

vivien

  • Administrateur
  • *
  • Messages: 47 079
    • Twitter LaFibre.info
Le combat PPPoA PPPoE IPoA IPoE
« Réponse #3 le: 03 juin 2011 à 17:03:19 »
Free utilisait un CISCO SCE 2000 pour brider les protocoles "indésirable" selon lui.

Pour faire de la QoS, il faut connaître le débit de synchro afin de laisser passer le trafic prioritaire selon cette règle : (débit de synchro - débit du flux prioritaire - petite marge). tout ce qui dépasse ce débit est droppé (ou bufferisé). Les CISCO SCE 2000 ne peuvent donc que dégrader certains flux et pas prioriser un trafic.

corrector

  • Invité
Le combat PPPoA PPPoE IPoA IPoE
« Réponse #4 le: 03 juin 2011 à 19:39:03 »
Free utilisait un CISCO SCE 2000 pour brider les protocoles "indésirable" selon lui.
C'est à dire tout sauf Web (et peut-être mail).

Et par "brider", il faut comprendre rendre parfois inutilisable, au point de ressortir le modem bas débit du grenier.

Pour faire de la QoS, il faut connaître le débit de synchro afin de laisser passer le trafic prioritaire selon cette règle : (débit de synchro - débit du flux prioritaire - petite marge). tout ce qui dépasse ce débit est droppé (ou bufferisé). Les CISCO SCE 2000 ne peuvent donc que dégrader certains flux et pas prioriser un trafic.
Il s'agissait de shaping sur le réseau de collecte, pas sur la ligne de chaque abonné.

Et on peut faire du shaping sans connaitre le débit total.

corrector

  • Invité
PPPoE et configuration de la MTU
« Réponse #5 le: 12 juin 2011 à 02:27:02 »
  • En PPPoE : La fragmentation liée à la MTU de 1492
Si DHCP est utilisé pour la configuration IP des PC, il doit être possible d'utiliser Interface MTU Option (décrite dans RFC 2132 - DHCP Options and BOOTP Vendor Extensions), non?

vivien

  • Administrateur
  • *
  • Messages: 47 079
    • Twitter LaFibre.info
Le combat PPPoA PPPoE IPoA IPoE
« Réponse #6 le: 12 juin 2011 à 07:34:35 »
Aujourd'hui, il n'y a plus de fragmentation en ADSL mais les équipements modifient dans les paquets [SYN] et [SYN, ACK] le MSS (Maximum Segment Size) qui est habituellement à 1460 (20 octets d'entête IP et 20 octets d'entête TCP).

Ce qui ne règle que le problème du MTU sur le lien de collecte (pour TCP); si le MTU diminue après, il faudra bien que le système gère cela correctement.
C'est le cas dans une connexion L2TP (Layer 2 Tunneling Protocol) qui prend 40 octets d'en-tête en collecte.

Le PC client èmet un [SYN] avec MSS 1460, la connexion étant PPPoE, la box change le MSS à 1452. Dans le réseau l'équipement qui gère le L2TP va re-modifier le MSS à 1420.
Le serveur èmet un [SYN , ACK] avec MSS 1460, l'équipement qui gère le L2TP vo modifier le MSS à 1420. La box ne change pas le MSS qui est suffisamment bas pour le PPPoE.

Voici un exemple de [SYN, ACK] avec une connexion 3G Bouygues Telecom sous Linux (c'est une requête HTTP vers lafibre.info, serveur qui répond avec une MSS de 1460 octets). Le champ MSS a été modifié par un équipement à 1420 pour permettre de ne pas avoir de fragmentation :



corrector

  • Invité
Le combat PPPoA PPPoE IPoA IPoE
« Réponse #7 le: 12 juin 2011 à 09:06:43 »
Le PC client èmet un [SYN] avec MSS 1460, la connexion étant PPPoE, la box change le MSS à 1452. Dans le réseau l'équipement qui gère le L2TP va re-modifier le MSS à 1420.
Si le PC était informé du MTU du lien, il aurait déjà fixé le MSS à la bonne valeur.

D'où l'option DHCP.

corrector

  • Invité
Ajustement du MSS
« Réponse #8 le: 27 février 2012 à 14:25:33 »
Comment sais-tu que le MSS a été modifié en cours de route?

vivien

  • Administrateur
  • *
  • Messages: 47 079
    • Twitter LaFibre.info
Le combat PPPoA PPPoE IPoA IPoE
« Réponse #9 le: 27 février 2012 à 21:37:44 »
C'est simple : en plus de la capture coté client, je fais une capture coté serveur et je compare.

corrector

  • Invité
Le combat PPPoA PPPoE IPoA IPoE
« Réponse #10 le: 28 février 2012 à 02:53:05 »
C'est évident!

Il y a un service en ligne qui permet de faire ça?

vivien

  • Administrateur
  • *
  • Messages: 47 079
    • Twitter LaFibre.info
Le combat PPPoA PPPoE IPoA IPoE
« Réponse #11 le: 28 février 2012 à 06:25:38 »
Non, mais comme indiqué le serveur a distance est lafibre.info donc je peux faire une capture.

Si tu as besoin un jour de faire une capture coté serveur, contacte moi.