Re: [FRnOG] [TECH] Rapport sur la résilience de l'Internet en France
Bonjour à tous, Tout d'abord merci pour l'intérêt que vous avez porté au rapport et vos différents commentaires. L'ensemble des co-auteurs se joint à moi pour répondre à certaines de vos interrogations. 1] Retours sur les indicateurs du rapport L’Observatoire de la résilience de l’Internet français vise à identifier et mesurer à intervalles réguliers des indicateurs jugés représentatifs de la résilience. Un rapport annuel est publié afin de suivre l’évolution de la résilience. Un des objectifs à court terme est de proposer un ensemble de bonnes pratiques de déploiement. Si vous le souhaitez, nous pouvons vous transmettre les analyses relatives à vos AS respectifs, uniquement, dans des échanges bilatéraux. L'Observatoire étant neutre, il n'a pas vocation à diffuser des informations publiques sans les anonymiser. 2] Peering avec l'Observatoire L'objectif de l'Observatoire est d'étudier l'Internet français. Malheureusement, il n'existe pas de collecteur BGP public en France. Afin de palier à ce défaut, nous pensons qu'il serait souhaitable que les acteurs de l'Internet s'interconnectent avec un collecteur public (RIS, route-views). En tout état de cause, il serait préférable qu'un tel collecteur soit mis en place en France. Certains opérateurs ayant exprimé leur souhait de ne pas s'interconnecter avec des collecteurs publics, un collecteur BGP administré et géré par l'Observatoire sera mis en place, pour assurer la confidentialité de leurs informations. Il est enfin implicite que les filtres nécessaires (no-export, etc.) seront configurés sur ce collecteur. 3] Définition et nombre des AS français Le nombre d'AS français fourni dans le rapport est en effet inférieur à ceux que l'on trouve dans les bases publiques (RIPE, Cymru, etc.). La définition actuelle d'AS français (un AS voisin d'un des 4 AS étudiés dont les préfixes sont 'français' pour geoip) étant effectivement trop simple, nous travaillons à sa modification. Actuellement, la nouvelle définition permet d'identifier environ 1200 AS français. Enfin, les co-auteurs de ce rapport seront présents au FRnOG : Stéphane Botzmeyer (AFNIC), Samia Mtimet (AFNIC), Mohsen Souissi (AFNIC), François Contat (ANSSI), Guillaume Valadon (ANSSI). Nous serons disponibles pour discuter avec vous de l'Observatoire et du contenu du rapport. À demain, François --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] AT&T vs 4Chan
Ou sinon : http://www.merit.edu/mail.archives/nanog/msg19609.html Le 27 juillet 2009 14:11, Gregoire Villain a écrit : > De mieux en mieux... > http://www.theregister.co.uk/2009/07/27/att_censorship_block/ > > On peut pas dire que je sois le premier client de 4Chan, mais quand même, > c'est un peu une institution. > > Greg > not a /b/-tard !--- > Liste de diffusion du FRnOG > http://www.frnog.org/ > >
Re: [FRnOG] Troll du mardi
Merci d'arrêter le bruit inutile. La pollution du chan irc suffit. Le 25 janvier 2011 13:26, Raphaël Jacquot a écrit : > > Avec le rachat de dailymotion par orange, va t'on voir celui ci devenir > accessible uniquement derrière 5511 ? > Quels seraient les effets pour la plupart des fai mondiaux ? > > Vous avez 4 heures, ramassage des copies a 18h ! > > > Blue Networks > Accès internet en zones blanches--- > Liste de diffusion du FRnOG > http://www.frnog.org/ > >
Re: [FRnOG] Choix technologique IPoA vs PPPoA
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
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
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
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 > >
