Re: [FRnOG] Choix technologique IPoA vs PPPoA

2008-10-16 Par sujet Patrick Viet 
On Thu, Oct 16, 2008 at 10:40 AM, Splio - Benjamin BILLON
<[EMAIL PROTECTED]> wrote:
> Ah bah ça me fait plaisir, tiens, j'ai rien capté à la discussion mais CA
> c'est de mon niveau.

J'avoue que pour le coup, même si ce thread je le comprends, il me
casse les PIEDS de par sa monotonie et sa répétitivité ; donc quand un
BAS (broadband access server) devient un BRAS la réaction ne tarde
pas... !

- vous pouvez applaudir -

Patrick
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Choix technologique IPoA vs PPPoA

2008-10-16 Par sujet Splio - Benjamin BILLON 
Ah bah ça me fait plaisir, tiens, j'ai rien capté à la discussion mais 
CA c'est de mon niveau.


Patrick Viet a écrit :

Mais que feront le PIED et le COUDE ??

2008/10/16  <[EMAIL PROTECTED]>:
  

Oui c'est le BRAS qui va catché. Par contre c'est en fonction du BRAS :
Ca peut être à la fin du lease (ou à 50%) du temps si il n'y a pas de
nouvelle requete DHCP, ca peut être via un monitoring passif du CPE ou du
terminal client (ping ou plus de traffic, ...)


---
Liste de diffusion du FRnOG
http://www.frnog.org/

  

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Choix technologique IPoA vs PPPoA

2008-10-16 Par sujet Patrick Viet 
Mais que feront le PIED et le COUDE ??

2008/10/16  <[EMAIL PROTECTED]>:
>
> Oui c'est le BRAS qui va catché. Par contre c'est en fonction du BRAS :
> Ca peut être à la fin du lease (ou à 50%) du temps si il n'y a pas de
> nouvelle requete DHCP, ca peut être via un monitoring passif du CPE ou du
> terminal client (ping ou plus de traffic, ...)
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Choix technologique IPoA vs PPPoA

2008-10-16 Par sujet J . HIEZELY 
Oui c'est le BRAS qui va catché. Par contre c'est en fonction du BRAS :
Ca peut être à la fin du lease (ou à 50%) du temps si il n'y a pas de 
nouvelle requete DHCP, ca peut être via un monitoring passif du CPE ou du 
terminal client (ping ou plus de traffic, ...)

Jérôme HIEZELY
[EMAIL PROTECTED]

[EMAIL PROTECTED] a écrit sur 15/10/2008 22:20:19 :

> Juste pour info (peut être que quelqu'un l'a déjà mentionné) Avec le
> DHCP couplé au Radius on a bien un ACCT STOP quand le bail expire.
> 
> --- En date de : Dim 12.10.08, François Contat <[EMAIL PROTECTED]> a 
écrit :
> De: François Contat <[EMAIL PROTECTED]>
> Objet: Re: [FRnOG] Choix technologique IPoA vs PPPoA
> À: [EMAIL PROTECTED]
> Cc: "Liste FRnoG" , "Gregoire Villain" 
> <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Date: Dimanche 12 Octobre 2008, 13h47

> 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 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.
> > 
> > * 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).
> > 
> > 
> > IPoX :
> > 
> > * Aucune notion de session. On 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

Re: [FRnOG] Choix technologique IPoA vs PPPoA

2008-10-15 Par sujet EL MANSOURI Nabil 
Juste pour info (peut être que quelqu'un l'a déjà mentionné) Avec le DHCP 
couplé au Radius on a bien un ACCT STOP quand le bail expire.

--- En date de : Dim 12.10.08, François Contat <[EMAIL PROTECTED]> a écrit :

De: François Contat <[EMAIL PROTECTED]>
Objet: Re: [FRnOG] Choix technologique IPoA vs PPPoA
À: [EMAIL PROTECTED]
Cc: "Liste FRnoG" , "Gregoire Villain" <[EMAIL PROTECTED]>, 
[EMAIL PROTECTED]
Date: Dimanche 12 Octobre 2008, 13h47



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 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.
> 
> * 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).
> 
> 
> IPoX :
> 
> * Aucune notion de session. On 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 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

Re: [FRnOG] Choix technologique IPoA vs PPPoA

2008-10-14 Par sujet François Contat 
A condition d'avoir un BB prêt, et bien en parlant d'IPv4 que je souligne
ceci comme un problème :)

Le 14 octobre 2008 14:11, Raphaël Jacquot <[EMAIL PROTECTED]> a écrit :

> On Tue, 2008-10-14 at 13:52 +0200, François Contat wrote:
> > Bonjour,
> >
> > J'en profite pour rajouter un point "négatif" à l'IPoX : Consommation
> > d'IP qui revient à une IP par client alors que l'on est dans un modèle
> > plus "adaptif" dans le cas d'une collecte PPP. Bien entendu ceci n'a
> > pas forcément de sens dans le cas où l'on offre une ip fixe et un
> > subnet à un client B2B.
> >
> > Bref, dans le contexte où l'on nous rabache (encore...) que le nombre
> > d'IPv4 atteint son maximum d'utilisation, ce point n'est pas à
> > négliger.
> >
> > François Contat
>
> en effet. cependant, rien n'empeche (sinon le fait que le radius/dhcp ne
> le supporte pas) de fournir de l'ipv6 natif au client au passage
>
>

Re: [FRnOG] Choix technologique IPoA vs PPPoA

2008-10-14 Par sujet Raphaël Jacquot 
On Tue, 2008-10-14 at 13:52 +0200, François Contat wrote:
> Bonjour,
> 
> J'en profite pour rajouter un point "négatif" à l'IPoX : Consommation
> d'IP qui revient à une IP par client alors que l'on est dans un modèle
> plus "adaptif" dans le cas d'une collecte PPP. Bien entendu ceci n'a
> pas forcément de sens dans le cas où l'on offre une ip fixe et un
> subnet à un client B2B.
> 
> Bref, dans le contexte où l'on nous rabache (encore...) que le nombre
> d'IPv4 atteint son maximum d'utilisation, ce point n'est pas à
> négliger.
> 
> François Contat

en effet. cependant, rien n'empeche (sinon le fait que le radius/dhcp ne
le supporte pas) de fournir de l'ipv6 natif au client au passage

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Choix technologique IPoA vs PPPoA

2008-10-14 Par sujet François Contat 
Bonjour,

J'en profite pour rajouter un point "négatif" à l'IPoX : Consommation d'IP
qui revient à une IP par client alors que l'on est dans un modèle plus
"adaptif" dans le cas d'une collecte PPP. Bien entendu ceci n'a pas
forcément de sens dans le cas où l'on offre une ip fixe et un subnet à un
client B2B.

Bref, dans le contexte où l'on nous rabache (encore...) que le nombre d'IPv4
atteint son maximum d'utilisation, ce point n'est pas à négliger.

François Contat

Le 14 octobre 2008 13:04, Francois Bourdais <[EMAIL PROTECTED]> a
écrit :

>  Ce qui est amusant, c'est que certains (gros) opérateurs cherchent
> actuellement à coupler les mécanismes DHCP et RADIUS (par ex modif d'un
> serveur DHCP pour interroger un serveur RADIUS pendant la phase d'allocation
> d'@IP). Pas tres propre mais ca illustre la tendance.
>
>
>
> Je pense donc qu'IPoX présente pas mal d'atouts (dont Plug&play, couts,
> QoS…), sachant que le contrôle des infos de ligne (option 82) est dans ce
> cas indispensable (et il faut alors gérer les formats de sous options 82 si
> plusieurs types de relais sont utilisés). Il  y aussi très souvent des
> mécanismes propriétaires dans les équipements pour combler le pb d'absence
> de session avec DHCP (par ex sur le site Cisco, chercher « DHCP
> accounting »).
>
> Ou alors on peut effectivement parser les logs sur le serveur DHCP (pour
> avoir le Start) et utiliser un bail court + gestion d'évenement (ex. trigger
> sur expiration ou Release) pour faire un Acct Stop, mais ca fait un peu
> bricolage.
>
>
>
> Coté support client, si la PF de gestion coté DHCP est bien conçue, le
> support se passe plutôt tres bien, meme sur des réseaux tres gros. Faut pas
> avoir à parser des fichiers plats par contre J
>
>
>
> Francois
>
>
>
> *De :* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *De la part de
> * François Contat
> *Envoyé :* dimanche 12 octobre 2008 13:47
> *À :* [EMAIL PROTECTED]
> *Cc :* Liste FRnoG; Gregoire Villain; [EMAIL PROTECTED]
> *Objet :* Re: [FRnOG] Choix technologique IPoA vs PPPoA
>
>
>
> 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 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

RE: [FRnOG] Choix technologique IPoA vs PPPoA

2008-10-14 Par sujet Francois Bourdais 
Ce qui est amusant, c’est que certains (gros) opérateurs cherchent
actuellement à coupler les mécanismes DHCP et RADIUS (par ex modif d’un
serveur DHCP pour interroger un serveur RADIUS pendant la phase d’allocation
[EMAIL PROTECTED]). Pas tres propre mais ca illustre la tendance.

 

Je pense donc qu’IPoX présente pas mal d’atouts (dont Plug&play, couts,
QoS…), sachant que le contrôle des infos de ligne (option 82) est dans ce
cas indispensable (et il faut alors gérer les formats de sous options 82 si
plusieurs types de relais sont utilisés). Il  y aussi très souvent des
mécanismes propriétaires dans les équipements pour combler le pb d’absence
de session avec DHCP (par ex sur le site Cisco, chercher « DHCP accounting
»).

Ou alors on peut effectivement parser les logs sur le serveur DHCP (pour
avoir le Start) et utiliser un bail court + gestion d’évenement (ex. trigger
sur expiration ou Release) pour faire un Acct Stop, mais ca fait un peu
bricolage.

 

Coté support client, si la PF de gestion coté DHCP est bien conçue, le
support se passe plutôt tres bien, meme sur des réseaux tres gros. Faut pas
avoir à parser des fichiers plats par contre J

 

Francois

 

De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de
François Contat
Envoyé : dimanche 12 octobre 2008 13:47
À : [EMAIL PROTECTED]
Cc : Liste FRnoG; Gregoire Villain; [EMAIL PROTECTED]
Objet : Re: [FRnOG] Choix technologique IPoA vs PPPoA

 

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 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.
> 
> * 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).
> 
> 
> IPoX :
> 
> * Aucune notion de session. On a aucune information sur 
> l'utilisateur et son état et ne récupérons pas d'informations sur sa
> connexion contrairement au Radius. Ce po

Re: [FRnOG] Choix technologique IPoA vs PPPoA

2008-10-13 Par sujet Rachid Zitouni 
Dans tous les cas, si c'est pour creer une offre pour tes clients
entreprises, priveligies des encaps identiques de chaque cote.
Apres privelegies ipoX (dhcp ou static) a pppoX pour faire evoluer ton
service :-)

Le reste depend de tes propres equipements que tu auras a chaque extremite.


HiH
Rachid


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

> 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. Certa

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

Re: [FRnOG] Choix technologique IPoA vs PPPoA

2008-10-13 Par sujet Rachid Zitouni 
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 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).

Re: [FRnOG] Choix technologique IPoA vs PPPoA

2008-10-13 Par sujet Christophe Lucas 
daren crew ([EMAIL PROTECTED]) wrote:
> 
> Quelqu'un a-t-il un retour sur la collecte SDSL FT sur RAD? Que pensez-vous 
> de tout ça?

Salut,

A moins que je dise une connerie, mais tu dois pouvoir te faire livré en
ATM avec pour intermédiaire un Rad. En tous cas, c'est le nôtre.

A+

Christophe

---
Liste de diffusion du FRnOG
http://www.frnog.org/

RE: [FRnOG] Choix technologique IPoA vs PPPoA

2008-10-13 Par sujet daren crew 
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 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.

> 

> * 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).

> 

> 

> IPoX :

> 

> * Aucune notion de session. On 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 besoi

Re: [FRnOG] Choix technologique IPoA vs PPPoA

2008-10-12 Par sujet François Contat 
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 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.
> >
> > * 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).
> >
> >
> > IPoX :
> >
> > * Aucune notion de session. On 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 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

Re: [FRnOG] Choix technologique IPoA vs PPPoA

2008-10-11 Par sujet EL MANSOURI Nabil 
Bonjour
Je confirme. Effetivement aujourd'hui quasiment tous les équipements de type 
"subscriber management" (SE de Redback, SR7 d'Alcatel, Huawei, Cisco) 
supportent l'association DHCP/Radius permettant de bénéficier des avantages des 
deux. Et ça tourne depuis un bon moment. Attention, cependant le choix de 
l'équipement important. Tous dépend de ce qu'on faire excatement (Volumétrie, 
QoS, LAG, ...) . Il y a certaines subtilités.
Plus d'infos n'hésitez pas.

--- En date de : Ven 10.10.08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> a écrit :

De: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Objet: Re: [FRnOG] Choix technologique IPoA vs PPPoA
À: "François Contat" <[EMAIL PROTECTED]>
Cc: "Liste FRnoG" , "Gregoire Villain" <[EMAIL PROTECTED]>, 
[EMAIL PROTECTED]
Date: Vendredi 10 Octobre 2008, 20h27



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 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.
> 
> * 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).
> 
> 
> IPoX :
> 
> * Aucune notion de session. On 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 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.
> 
>

Re: [FRnOG] Choix technologique IPoA vs PPPoA

2008-10-10 Par sujet J . HIEZELY 
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 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.
> 
> * 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).
> 
> 
> IPoX :
> 
> * Aucune notion de session. On 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 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

Re: [FRnOG] Choix technologique IPoA vs PPPoA

2008-10-08 Par sujet François Contat 
Le retour du combat de l'IPoX vs PPPoX.

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.

* 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).


IPoX :

* Aucune notion de session. On 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 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 ruptu

Re: [FRnOG] Choix technologique IPoA vs PPPoA

2008-10-03 Par sujet J . HIEZELY 
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 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
> 
> A mon sens, PPPoX est sincèrement plus complexe opérationnellement à
> gérer que de l'IPoA.
> IPoA se rapproche largement plus d'un modèle de leased line, qui 
> déjà est philosophiquement plus léger, sans parler du gain en perf. 
> A mon avis, PPP avait du sens en dialup et n'en a plus autant 
maintenant. 
> Surtout que je pense que PPPoX n'a été utilisé pendant longtemps que
> pour conserver une similarité avec le dial dans les SI.
> De nos jours, d'excellents systèmes de provisioning permettent de 
> faire aussi bien l'un que l'autre, au pire, ca ne représente pas une
> somme monstrueuse de travail que d'en coder un. (je pensais a 
> Visionael/Comptel pour le provisioning out of the box).
> Par contre c'est vrai que tu peux faire de l'accounting un peu 
> poussé avec les tickets RADIUS.
> Le truc sympa aussi, c'est si un jour tu veux faire du controle 
> parental, tu peux le faire avec plusieurs sessions PPP différentes 
> pour des users différents sur la même machine (on n'y pense pas à 
> ca... mais c'est plus sain que fournir des softs mal fichus à ses 
abonnés).
> 
> Donc d'un point de vue ingénierie, je dirais volontiers go IPoA.
> 
> Greg

Re: [FRnOG] Choix technologique IPoA vs PPPoA

2008-10-03 Par sujet Gregoire Villain 


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


A mon sens, PPPoX est sincèrement plus complexe opérationnellement à  
gérer que de l'IPoA.
IPoA se rapproche largement plus d'un modèle de leased line, qui déjà  
est philosophiquement plus léger, sans parler du gain en perf. A mon  
avis, PPP avait du sens en dialup et n'en a plus autant maintenant.
Surtout que je pense que PPPoX n'a été utilisé pendant longtemps que  
pour conserver une similarité avec le dial dans les SI.
De nos jours, d'excellents systèmes de provisioning permettent de  
faire aussi bien l'un que l'autre, au pire, ca ne représente pas une  
somme monstrueuse de travail que d'en coder un. (je pensais a  
Visionael/Comptel pour le provisioning out of the box).
Par contre c'est vrai que tu peux faire de l'accounting un peu poussé  
avec les tickets RADIUS.
Le truc sympa aussi, c'est si un jour tu veux faire du controle  
parental, tu peux le faire avec plusieurs sessions PPP différentes  
pour des users différents sur la même machine (on n'y pense pas à  
ca... mais c'est plus sain que fournir des softs mal fichus à ses  
abonnés).


Donc d'un point de vue ingénierie, je dirais volontiers go IPoA.

Greg

Re: [FRnOG] Choix technologique IPoA vs PPPoA

2008-10-03 Par sujet Vivien GUEANT 

daren crew a écrit :
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...
Attention, pour la VoIP (petits paquets), si on prend du G711 et un 
paquet généré toutes les 20ms,  le PPPoE utilise 3 paquets ATM (le CPE 
est obligé de bourrer pour remplir le 3éme paquet ATM qui à une taille 
fixe). En PPPoA, on utilise 2 paquets ATM.


=> On peut dans un lien SDSL faire transiter 1/3 de plus de 
communications G711, si on utilise le PPPoA ou l'IPoA à la place du PPPoE.


Vivien.

Re: [FRnOG] Choix technologique IPoA vs PPPoA

2008-10-03 Par sujet Clement Cavadore 
Hello,

On Fri, 2008-10-03 at 14:28 +, daren crew wrote:
> Alors quoi? Si quelqu'un en sait plus je suis preuneur

Avantages du PPP: Tu les as mentionné, beaucoup plus simple à gérer coté
ISP. 

Inconvénient majeur: problèmes de MTU (pour le PPPoE, le PPPoA et PPTP
ne sont pas concernés)


Avantages de l'IPoA: Ils ont étés également mentionnés, c'est beaucoup
plus facile pour le troubleshooting, et il est possible de faire du
provisionning automatique (en ayant un bon SI). 

Inconvénient: Non mobilité de l'IP en cas de changement de DSLAM du
client (ca dépend de la politique de l'ISP), sécurité supplémentaire à
gérer en cas de takeover d'IP (Si tu fais un subnet pour X clients, ou
sinon, gâchis d'IP en mettant des /30 aux clients, solution qui pourrait
quand même résoudre le premier problème de "non mobilité de l'IP")

Bref, j'aurais quand même tendance à préférer l'IPoA. Ou alors le PPP,
si et seulement si tu maitrises tous les CPE de tes clients.


-- 
Clément Cavadore

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Choix technologique IPoA vs PPPoA

2008-10-03 Par sujet Rachid Zitouni 
Hello,

La QoS avance (autre que SPQ) peut faire pencher la balance en faveur de
l'ipoa.
Cela peut devenir tres complique sur pppoa/oe/oaoe ...
La VoIP peut egalement pencher la balance en faveur de l'ipoa
La gestion du nombre de com supportes peut tres vite devenir un casse tete
...
L'aspect operationnel (provisionning) est clairement en faveur de ppp sauf
peut etre pour la partie post provisionning (snmp, troubleshooting et
maintenance dans le temps)
Ma cl : pppoX pour les soho et residentiel sans qos avancee avec max une com
voip et ipoX pour les services avances.
L'autre inconvenient : ppp n'est pas gere de la meme facon par tous les
vendeurs :-)

HiH
Rachid



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

> 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 ! Téléchargez Messenger,
> c'est gratuit ! 
>