pppOe et PPPoA

Le Mon, 12 Dec 2005 18:18:21 +0100, Herm a écrit :

"Walter" a écrit dans le message de news:...

Quelque lecture ici :

[Liens]

Bonsoir,

Merci pour ces liens !

C'est donc bien cela, les limites entre BAS et DSLAM deviennent moins
marqués, au fur et à mesure que des fonctionnalités BAS (la gestion du
protocole ATM)sont intégrées dans les DSLAMs...

euhh non. La gestion du protocole ATM est déjà complètement intégré
dans le DSLAM et l'a toujours été. C'est bien dans le DSLAM, qu'est
réalisé la cross-connection 8/35 vers un couple VPi/VCi qui tire vers le
BAS. Le DSLAM joue le rôle d'un switch ATM.
Par contre, la tendance en effet est de faire "descendre l'IP" plus bas
dans le réseau, jusqu'au DSLAM à terme.

"Walter" a écrit ...

Bonsoir Herm,

Comme vous l'a répondu Bloody, l'ATM est intégré au Dslam tant du coté
Réseau (backbone) que du coté utilisateur où il est porté par xDSL.
Le couple VPi/VCi cross connecté par le switch interne du Dslam est
prolongé jusqu'au BAS.

Bonjour

Merci à Bloody et à vous... Je voyais le DSLAM comme une sorte de "hub"
(style sauce Ethernet) qui se contentait de rediriger les flux ATM des
abonnés vers le DSLAM, sans avoir à les interprêter... Et je ne voyais pas
comment pouvait se faire la liaison DSLAM - BAS... Tout faux là...

Et d'une, je viens de voir qu'il n'existe pas d'équipement de type hub en
technologie ATM, qu'il n'y a que des switchs, et de deux, le système ne peut
fonctionner que si on garde un lien point-à-point entre l'abonné et le
BAS... Avec des abonnés (pratiquement tous) sur un même canal ATM (8,35)
entre leur modem abonné et le DSLAM, il fallait pourtant bien que le BAS
centralisateur s'y retrouve...

Si je suis bien, ça veut-il dire que sur une liaison DSLAM - BAS, on a
plusieurs canaux ATM, un pour chaque abonné de ce DSLAM ? Et que le DSLAM
fait des cross-conections entre le (8,35) (ou autre) côté abonné et un canal
(x,y) reservé côté BAS ?

Dans le cas d'un Dslam avec interface réseau Ethernet, il ne reste plus
que
l'acces abonné ou on trouve encore de l'ATM ou dans les raccordement de
Dslam chainés (plusieurs Dslam en cascade) s'ils sont raccordée par des E1
en IMA.

Ok pour l'IMA, j'ai pu retrouver des docs chez Cisco... Multiplexage des
cellules ATM sur un groupement de liens E1, pour raison de coûts
(réutilisation de câblage pré-existant ?), plutôt que de tirer de nouveaux
câbles directement aptes aux débits nécessaires... Cela simule une liaison
pure ATM.

Par contre, dans un DSLAM ayant une liaison Ethernet avec le BAS, comment le
lien point-à-point est-il maintenu ? Via un protocole de tunnelling (L2TP ?)
qui amène les sessions PPP abonnés jusqu'au BAS (abaissant du même coup le
MTU IP utilisable par l'abonné) ?

Par analyseur de trames Ethernet, en regardant les trames d'initialisation
de connexion TCP/IP (le champ MSS des trames SYN de TCP) sur ma ligne il y a
quelque temps, j'avais pu voir que le MTU max sur ma ligne était de 1460
octets, malgré le fait que je me connecte en PPPoA (qui permet le MTU 1500)
depuis un modem-routeur Ethernet (limite 1500 là-aussi). Valeur confirmée
par www.dslreports.com/tweak .

Chose amusante : les pings (ICMP/IP) passent même si le paquet ping fait
1500 octets et que le flag DF est mis (je viens de voir que certains
matériels savaient manipuler le flag DF, comme indiqué dans le lien cisco
ci-dessous).

Les 40 octets de différence me faisaient penser à la taille des en-têtes de
PPPoL2TPoUDPoIP :
http://www.cisco.com/warp/public/471/l2tp_mtu_tuning.html
PPP : 4 ; L2TP : 8 ; UDP : 8 ; IP : 20 ; Total = 40.

Ce pourrait-il que ça soit dû à un DSLAM à raccordement Ethernet ?

Merci pour ce partage de connaissances ;-)

--
Herm

Le mer, 14 déc 2005 at 11:49 GMT, Herm <a@a.invalid> a écrit :

"Walter" a écrit ...
Si je suis bien, ça veut-il dire que sur une liaison DSLAM - BAS, on a
plusieurs canaux ATM, un pour chaque abonné de ce DSLAM ? Et que le DSLAM
fait des cross-conections entre le (8,35) (ou autre) côté abonné et un canal
(x,y) reservé côté BAS ?

C'est bien ça.
Chez Nerim, dans l'interface de gestion de son compte, où on a un
historique des connexions, on voit ces valeurs, par exemple.
(il est d'ailleurs rigolo, parfois, de voir que suite à un probleme qui
"n"existait pas" chez FT, il y a eu un changement de ces valeurs ;-)

[...]

Par contre, dans un DSLAM ayant une liaison Ethernet avec le BAS, comment le
lien point-à-point est-il maintenu ? Via un protocole de tunnelling (L2TP ?)
qui amène les sessions PPP abonnés jusqu'au BAS (abaissant du même coup le
MTU IP utilisable par l'abonné) ?

L2TP est utilisé entre le BAS et les LNS du FAI.
Dans le cas d'un DSLAM avec connexion ethernet, c'est qu'il s'agit d'un
DSLAM IP, et dans ce type de conf, il n'y a plus de BAS.

Par analyseur de trames Ethernet, en regardant les trames d'initialisation
de connexion TCP/IP (le champ MSS des trames SYN de TCP) sur ma ligne il y a
quelque temps, j'avais pu voir que le MTU max sur ma ligne était de 1460
octets, malgré le fait que je me connecte en PPPoA (qui permet le MTU 1500)
depuis un modem-routeur Ethernet (limite 1500 là-aussi). Valeur confirmée
par www.dslreports.com/tweak .

Le MSS d'une connexion TCP est de 40 octets inférieur à la MTU.
(correspondant aux entetes IP et TCP)


Dom

Salut,

Si je suis bien, ça veut-il dire que sur une liaison DSLAM - BAS, on a
plusieurs canaux ATM, un pour chaque abonné de ce DSLAM ?

Oui. Un canal virtuel pour chaque abonné de ce DSLAM routé sur ce BAS.
On peut imaginer que tous les abonnés d'un DSLAM ne sont pas routés sur
le même BAS.

Et que le DSLAM fait des cross-conections entre le (8,35) (ou autre)
côté abonné et un canal (x,y) reservé côté BAS ?

Oui. Un canal virtuel peut avoir des identifiants VPI/VCI différents sur
chaque segment ATM emprunté. Chaque switch ATM doit faire la
correspondance pour assurer la continuité de la liaison point à point.
Le DSLAM joue lui-même le rôle d'un switch ATM.

[...]

Par contre, dans un DSLAM ayant une liaison Ethernet avec le BAS, comment le
lien point-à-point est-il maintenu ?

Je ne suis pas sûr qu'il existe de DSLAM ethernet dans le modèle de
collecte PPP avec BAS.

Via un protocole de tunnelling (L2TP ?)
qui amène les sessions PPP abonnés jusqu'au BAS (abaissant du même coup le
MTU IP utilisable par l'abonné) ?

Pourquoi donc ? Le tunnelling L2TP/UDP existe déjà entre le BAS et le
LNS sans que le MTU de l'IP encapsulé en soit affecté.

Par analyseur de trames Ethernet, en regardant les trames d'initialisation
de connexion TCP/IP (le champ MSS des trames SYN de TCP) sur ma ligne il y a
quelque temps, j'avais pu voir que le MTU max sur ma ligne était de 1460
octets, malgré le fait que je me connecte en PPPoA (qui permet le MTU 1500)

*MTU* à 1460 (et donc MSS à 1420) ou *MSS* à 1460 (et donc MTU à 1500) ?
En fait PPPoA permet un MTU bien plus grand que ça, de l'ordre de 9000.

Chose amusante : les pings (ICMP/IP) passent même si le paquet ping fait
1500 octets et que le flag DF est mis

Donc MTU à 1500. Par contre il est possible que le LNS de ton FAI limite
le MSS des paquets TCP SYN à 1420 afin que la taille des datagrammes
L2TP ne dépasse pas 1500, évitant ainsi leur fragmentation (fragmenter,
router les fragments et réassembler c'est du boulot en plus).

Les 40 octets de différence me faisaient penser à la taille des en-têtes de
PPPoL2TPoUDPoIP

oEthernet. Bien vu.

Ce pourrait-il que ça soit dû à un DSLAM à raccordement Ethernet ?

Plutôt au racordement Ethernet du LNS du FAI, AMA. Chez mon FAI Nerim,
les routeurs Cisco qui servent de LNS ont une option pour faire ça en
IPv4 (mais pas en IPv6) qui sert à limiter le MSS TCP à 1420.

Le Wed, 14 Dec 2005 15:17:19 +0100, Dominique ROUSSEAU a écrit :

Le mer, 14 déc 2005 at 11:49 GMT, Herm <a@a.invalid> a écrit :

"Walter" a écrit ...
Si je suis bien, ça veut-il dire que sur une liaison DSLAM - BAS, on a
plusieurs canaux ATM, un pour chaque abonné de ce DSLAM ? Et que le DSLAM
fait des cross-conections entre le (8,35) (ou autre) côté abonné et un canal
(x,y) reservé côté BAS ?

C'est bien ça.
Chez Nerim, dans l'interface de gestion de son compte, où on a un
historique des connexions, on voit ces valeurs, par exemple.
(il est d'ailleurs rigolo, parfois, de voir que suite à un probleme qui
"n"existait pas" chez FT, il y a eu un changement de ces valeurs ;-)

[...]

Par contre, dans un DSLAM ayant une liaison Ethernet avec le BAS, comment le
lien point-à-point est-il maintenu ? Via un protocole de tunnelling (L2TP ?)
qui amène les sessions PPP abonnés jusqu'au BAS (abaissant du même coup le
MTU IP utilisable par l'abonné) ?

L2TP est utilisé entre le BAS et les LNS du FAI.
Dans le cas d'un DSLAM avec connexion ethernet, c'est qu'il s'agit d'un
DSLAM IP, et dans ce type de conf, il n'y a plus de BAS.

Non pas forcément, Ce n'est pas parce qu'un DSLAM est en ethernet du

côté collecte qu'il devient de facto un DSLAM IP.
On peut par exemple choisir de ne gérer que du niveau 2 dasn le DSLAM
avec par exemple une cross connection VPi/VCi<->VLANid. Ensuite un réseau
de collecte de niveau 2, du MPLS...et on peut tout à fait imaginer la
présence d'un BAS avec la perpétuation de la traditionnelle archtecture
à base de PPP.
On peut aussi choisir d'inclure les fonctions de routage directement
dans le DSLAM et là en effet c'est un DSLAM IP.

"Pascal@plouf" a écrit dans le message de news: ...

Salut,

Bonsoir,

Par analyseur de trames Ethernet, en regardant les trames
d'initialisation de connexion TCP/IP (le champ MSS des trames SYN de TCP)
sur ma ligne il y a quelque temps, j'avais pu voir que le MTU max sur ma
ligne était de 1460 octets, malgré le fait que je me connecte en PPPoA
(qui permet le MTU 1500)

*MTU* à 1460 (et donc MSS à 1420) ou *MSS* à 1460 (et donc MTU à 1500) ?

Oui, pardon, cela peut prêter à confusion...

Dans le champ MSS, j'avais trouvé 1420, donc un MTU max exploitable valant
1460, en TCP/IP.

Et pourtant le ping à 1500 octets passe "apparemment" sans fragmentation.

J'avais été surpris de cette différence de comportement d'un protocole (TCP)
à l'autre (ICMP), alors que le support est le même (IP sur PPPoA).

Pour ceux qui aiment optimiser leur liaison en alignant le MTU sur un nombre
entier de cellules ATM, la limite maximale ne peut pas être trouvée par
ping, mais en analysant le champ MSS des trames SYN de TCP...

En fait PPPoA permet un MTU bien plus grand que ça, de l'ordre de 9000.

En théorie, jusqu'à 65533 octets (RFC 2364 "PPP over AAL5" : 2^16 -1, auquel
il faut enlever 2 octets pour PPP dans ce contexte).
http://www.faqs.org/rfcs/rfc2364.html

Cependant RFC 2364 fait référence au RFC 1661 "The Point to Point Protocol"
qui définit un une taille de données transportées (l' "Information field")
de 1500 octets maximum par défaut (le MRU Maximum Receive Unit).
http://www.faqs.org/rfcs/rfc1661.html

En IPoA, par contre, ça peut monter à 9180 octets, RFC 1626...
http://www.faqs.org/rfcs/rfc1626.html

Chose amusante : les pings (ICMP/IP) passent même si le paquet ping fait
1500 octets et que le flag DF est mis

Donc MTU à 1500. Par contre il est possible que le LNS de ton FAI limite
le MSS des paquets TCP SYN à 1420 afin que la taille des datagrammes L2TP
ne dépasse pas 1500, évitant ainsi leur fragmentation (fragmenter, router
les fragments et réassembler c'est du boulot en plus).

C'est ce que je pense aussi... Donc MTU -sans fragmentation- à 1460, et non
1500.

--
Herm

Dans le champ MSS, j'avais trouvé 1420, donc un MTU max exploitable valant
1460, en TCP/IP.

Je ne vois pas les choses de cette façon. Le MTU peut influer sur le
MSS, mais pas le contraire. Le MTU est une limite absolue, la taille
maxi de paquet qu'on peut recevoir ou émettre sur une interface ou un
chemin. Le MSS, en revanche, c'est une convention décidée entre deux
machines à l'établissement d'une connexion TCP pour définir la taille
maxi de segment TCP. En général on prend MSS = (MTU - tailles des
en-têtes IP et TCP) mais on pourrait prendre plus. Dans ce cas la taille
d'un datagramme IP contenant un segment TCP serait supérieur au MTU donc
la couche IP fragmenterait, ça ne serait pas efficace mais ça marcherait
quand même.

Ici le MSS est limité "sournoisement" par un équipement intermédiaire
(le LNS) dont ce n'est pas le rôle parce qu'une valeur supérieure
génèrerait une fragmentation massive "cachée" du tunnel L2TP
sous-jacent, et qui ne peut être détectée par des méthodes comme Path
MTU Discovery : la couche IP encapsulante est incapable de générer des
erreur ICMP "fragmentation needed" vers la couche IP encapsulée.

Et pourtant le ping à 1500 octets passe "apparemment" sans fragmentation.

Du point de vue de "ta" couche IP, oui. Par contre du la couche IP
sous-jacente qui a un MTU de 1500 et supporte le tunnel L2TP qui
transporte ta session PPP, il y a inévitablement fragmentation.

J'avais été surpris de cette différence de comportement d'un protocole (TCP)
à l'autre (ICMP), alors que le support est le même (IP sur PPPoA).

C'est forcément "sale" pour un équipement de niveau 2/3 (LNS) de
modifier un champ qui appartient au niveau 4. Note que les routeurs
PPPoE font souvent la même chose pour limiter le MSS à 1452.

Pour ceux qui aiment optimiser leur liaison en alignant le MTU sur un nombre
entier de cellules ATM, la limite maximale ne peut pas être trouvée par
ping, mais en analysant le champ MSS des trames SYN de TCP...

En effet...