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" <frnog@frnog.org>, "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 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 > > > 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
