[FRnOG] Choix technologique IPoA vs PPPoA

2008-10-03 Par sujet daren crew
Bonjour à tous,

Quelqu'un aurait-il des informations qui pourraient faire pencher la balance 
entre IPoA et PPPoA/E, surtout dans les supports de type SHDSL...

Avec le PPP, il est vrai que l'administration est on ne peut plus aisée... il 
suffit d'un RADIUS bien provisionné, et le tour est joué... c'est, semble-t-il, 
bien pour cela que nos amis opérateurs ont abandonné le reste...

Mais qui dit session dit rupture possible, mauvais comportement de l'équipement 
de terminaison qui, par exemple, ne retente pas forcément de se connecter en 
cas de rupture (même en mode always on), MTU (pour le pppoe) et j'en passe.

Avec l'IPoA, pas de session, donc pas les problèmes mentionnés précédemment, 
mais pas non plus d'authentification et donc pas de véritable contrôle simple 
du traffic et tout, ou presque est configuré de manière statique... donc en 
facilité de gestion, il y a mieux...

Alors comment se décider... Dans le cas de particuliers, il reboot de temps en 
temps n'est pas forcément gênant, mais dans le monde des entreprises (et de la 
VoIP) ce n'est pas forcément ce qu'il y a de mieux. Et d'ailleurs, chez Nerim, 
comme chez Colt, à ma connaissance, pour leurs SDSL, ils n'utilisent pas de 
PPP mais pourquoi...


J'ai tout d'abord pensé, outre les problèmes bien connus du PPP, aux 
performances...
L'encapsulation ? Ce ne sont pas quelques octets de plus qui constituent une 
différence transcendante... ni même le temps de traitement, on a dépassé ce 
stade depuis des décénnies ;) la fragmentation liée à la MTU (en pppoe)... les 
routeurs modernes font avec...

Alors quoi? Si quelqu'un en sait plus je suis preuneur

Merci d'avance pour votre aide !

Daren

_
Téléchargez le nouveau Windows Live Messenger !
http://get.live.com/messenger/overview

RE: [FRnOG] Choix technologique IPoA vs PPPoA

2008-10-13 Par sujet daren crew
n 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 gens bloquent le 

> ping. Après il existe peut-être une recette magique à laquelle je


> n'ai jamais pensé et si elle existe je suis preneur!

> 

> Ce point de notion de session est le plus sensible à mon sens.

> 

> * 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 ressente : une encapsulation / descapsulation en


> moins. Et dans le cas de petits paquets arrivant à un débit 

> important, les performances du modem peuvent s'en trouver TRES 

> 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
=> la 

> cpu de ce dernier atteint très vite les 100% CPU

> 

> 

> En gros, si tu n'as pas de gros besoins de support l'IPoX est LA 

> solution à retenir. Dans l'autre cas, à moins de trouver un paliatif

> à la notion de session (ex : snmp entre les modems et une plateforme

> de collecte d'information clients dans ton infrastructure, etc..)
et

> que tu as besoin de stats basées sur les infos terrains et fiables,


> alors le PPP est la solution à retenir tout en prenant compte du 

> fait que cette solution coute cher.

> 



> Le 3 octobre 2008 20:32, <[EMAIL PROTECTED]>
a écrit :

> 

> IPoA, une bonne architecture avec DHCP et la gestion de l'option 82


> DHCP et une authentification radius basée sur la mac@ et sur le 

> port. C'est plus simple pour les opérateurs que du PPP, le 

> provisionning est simplifié, pas d'action de la part de 

> l'utilisateur, ca marche dès la sortie du carton et ca ouvre les 

> nouveaux services. L'accounting est toujours possible. 

> 

> Jérôme HIEZELY

> [EMAIL PROTECTED] 

> 

> [EMAIL PROTECTED] a écrit sur 03/10/2008 19:43:40 :

> 

> 

> > On Oct 3, 2008, at 4:28 PM, daren crew wrote:

> 

> > 

> > Bonjour à tous,

> > 

> > Quelqu'un aurait-il des informations qui pourraient faire pencher
la

> > balance entre IPoA et PPPoA/E, surtout dans les supports de type
SHDSL...

> > 

> > Avec le PPP, il est vrai que l'administration est on ne peut
plus 

> > aisée... il suffit d'un RADIUS bien provisionné, et le tour est


> > joué... c'est, semble-t-il, bien pour cela que nos amis opérateurs


> > ont abandonné le reste...

> > 

> > Mais qui dit session dit rupture possible, mauvais comportement
de 

> > l'équipement de terminaison qui, par exemple, ne retente pas


> > forcément de se connecter en cas de rupture (même en mode always


> > on), MTU (pour le pppoe) et j'en passe.

> > 

> > Avec l'IPoA, pas de session, donc pas les problèmes mentionnés


> > précédemment, mais pas non plus d'authentification et donc pas
de 

> > véritable contrôle simple du traffic et tout, ou presque est


> > configuré de manière statique... donc en facilité de gestion,
il ya mieux...

> > 

> > Alors comment se décider... Dans le cas de particuliers, il reboot


> > de temps en temps n'est pas forcément gênant, mais dans le monde
des

> > entreprises (et de la VoIP) ce n'est pas forcément ce qu'il y
a de 

> > mieux. Et d'ailleurs, chez Nerim, comme chez Colt, à ma 

> > connaissance, pour leurs SDSL, ils n'utilisent pas de PPP
mais

> pourquoi...

> > 

> > 

> > J'ai tout d'abord pensé, outre les problèmes bien connus du PPP,
aux

> > performances...

> > L'encapsulation ? Ce ne sont pas quelques octets de plus qui


> > 

RE: [FRnOG] Choix technologique IPoA vs PPPoA

2008-10-13 Par sujet daren crew
Le truc c'est que la porte n'est pas encore livrée... et que j'essaye de 
référencer l'ensemble des possibilités.

Le seul truc que je sais c'est qu'au niveau de la porte ils fournissent un RAD 
http://www.rad-france.fr/Article/0,6583,33987-Unite_terminaison_reseau_multiservice,00.html

J'ai cru comprendre que FT nous offrait deux possibilités : livrer directement 
leurs CPE sur place qui feraient de l'ethernet soit terminaison classique 
modem de notre choix.

Voilà le topo



Date: Mon, 13 Oct 2008 17:46:20 +0200
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [FRnOG] Choix technologique IPoA vs PPPoA
CC: frnog@frnog.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]

RAD c'est pour faire plus que du bi paires, l'offre 8M sdsl avec un trunking 
atm sur le dslam et sur le cpe, non ?
dans tous les cas, si ils te mettent un RAD pour ce type de besoin, alors tu 
vas peut etre devoir gerer des encapsulations differentes entre ton cpe et ton 
routeur edge. 

A propos, tu ne dis pas si ta livraison cote edge est atm ?
Dans ce cas, si tu fais du pppoe cote cpe, tu devras faire du pppoeoa cote edge
Si tu fais de l'ipoe cote cpe, tu devras faires de l'ipoeoa cote edge.

Je dois dire que ppp ou ipox dans ce cas n'est pas la vraie question mais 
plutot, est ce que tu t'accomoderas d'encap differentes aux deux extremites ( 
je me souviens d'une offre turbo dsl de ft avec une interface ethernet 10 half 
cote cpe et un pvc cote pe :-) ?

Oui, parce que le but d'une offre sdsl est bien d'offrir un debit symetrique. 
Or, avec des encap differentes des deux cotes, le resultat est que ton cpe ou 
ton router edge verront un debit different :-) Et si tu veux faire de la QoS 
avancee, du reporting et tout ce qui s'en suit : ce sera un bon exercice mais 
il y a plus simple entre nous.

Pour resumer tres vite :
Dans ton cas, je verifierais d'abord si on a une encap identique de chaque cote 
puis dans un second temps, ppp ou ipox ...

HiH
Rachid 
 




Le 13 octobre 2008 16:31, daren crew <[EMAIL PROTECTED]> a écrit :





Merci à tous pour toutes ces bonne
infos, surtout pour vos retour au niveau performances. Concernant
l'acct et l'interfaçage RADIUS/DHCP, j'avais déjà pu mettre les doigts
dans le camboui, et ça marchait plutôt bien.



Le seul hic dans tout ça, sauf erreur de ma part, c'est que l'option 82
n'est valable que si on maîtrise les liaisons de bout à bout (notamment
DSLAM), mais ça n'est, à priori, pas disponible sur de la collecte FT,
je me trompe?



J'ai été très étonné de me voir fournir par FT un RAD (moi qui
m'attendais à une arrivée brute ATM, et donc à pouvoir faire tout, ou
presque, ce que je veux).

J'avoue que je m'inquiète un peu car, le RAD ayant une terminaison
ethernet et étant géré par FT, si je devais malgré tout utiliser du
PPP, d'être contraint à utiliser du pppoe (et donc MTU réduite), à
moins que le RAD gère la conversion...

De plus, je ne sais pas si l'IPoA reste aussi interessant quand on ne maîtrise 
pas le circuit de A à Z.



Quelqu'un a-t-il un retour sur la collecte SDSL FT sur RAD? Que pensez-vous de 
tout ça?





Date: Sun, 12 Oct 2008 13:47:16 +0200
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]

Subject: Re: [FRnOG] Choix technologique IPoA vs PPPoA
CC: frnog@frnog.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]


Bien
entendu que la liaison dhcp vers radius est possible, seulement c'est
de notion de session qu'il est question. 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.


Le point que j'ai soulevé dans le mail ne concerne en aucun cas
l'authentification choisie mais les informations sur un utilisateur à
l'instant T.


Le 10 octobre 2008 20:27,  <[EMAIL PROTECTED]> a écrit :



Je ne suis pas entièrement d'accord,
on peut coupler la notion DHCP et RADIUS. Certains équipements (routeurs
multi-services comme le 7750 d'ALCATEL ou CISCO ou JUNIPER, ...) permettent
de bloquer certaines requêtes DHCP et d'effectuer une requête radius et
de les libérer, ou alors de faire une requête d'accounting dès qu'ils voyent
passer ces requêtes. On peut alors bénéficier de l'authentification radius,
basée sur des éléments du type MAC, OPTION82, ... et avoir des informations
de début de session réel (lors du DHCP ACK renvoyé par le client quand
il obtient une IP par exemple). Par contre la fin de session peut selon
les équipements être aléatoire (en fonction de la durée des lease DHCP).





Sinon de manière plus générale

Jérôme HIEZELY

[EMAIL PROTECTED]



[EMAIL PROTECTED] a écrit sur 08/10/2008 14:49:43
:



> Le retour du combat de l'IPoX vs PPPoX.

> 

> PPPoX :

> 

> * L'avantage de