Re: [FRnOG] [MISC] FRNOG 19.0 - RELEASE
Bonjour, N'oubliez pas, FRNOG c'est ce vendredi. Si vous avez oublié de vous inscrire, le process est simple : 1 - petit e-mail a moi-même 2 - venir a la réunion... et si plus de siège, vous restez debout :) Si vous ne pouvez pas venir, envoyez moi un e-mail qui dit l'essentiel dans le sujet (c'est plus rapide). Le programme de la prochaine réunion FRNOG est désormais en ligne. http://www.frnog.org/?page=frnog19 Cordialement, -- Philippe Bourcier web : http://sysctl.org/ blog : http://zsysctl.blogspot.com --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] Pour les utilisateurs d'ARF...
Je crois que j'avais déjà demandé ici mais sans avoir de réponse. Qui utilise le format ARF, en sortie pour envoyer des rapports ou en entrée pour les analyser ? Qui l'ouvre à ses utilisateurs en leur permettant d'envoyer du ARF (explicitement ou via un formulaire) ? L'ARCEP devrait-elle récolter de l'information sur l'utilisation d'ARF ? Nouveau RFC 6650: Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF) : http://www.bortzmeyer.org/6650.html Auteur(s) du RFC: J. Falk (Return Path), M. Kucherawy (Cloudmark) Chemin des normes Le format ARF, normalisé dans le RFC 5965 permet à des acteurs de l'Internet (typiquemet des FAI et des gros hébergeurs de courrier comme Gmail) de s'envoyer des rapports structurés, produits et analysés automatiquement, au sujet des abus commis avec le courrier électronique, notamment du spam. Ce nouveau RFC du groupe de travail qui a conçu ARF expose comment et dans quelles circonstances utiliser ARF. L'idée de base d'ARF était qu'un message serait détecté comme abusif (par exemple par l'utilisateur cliquant un bouton « C'est du spam ! ») et que cette détection déclencherait l'envoi d'un rapport ARF au responsable (qui pourra le faire suivre, si nécessaire). En comparaison avec un rapport non structuré, l'avantage d'ARF est que les messages ARF seront analysables par des programmes, pour rendre leur traitement plus efficace. (Il existe des extensions à ARF pour des usages qui ne sont pas forcément des abus ou des erreurs d'authentification, comme l'extension du RFC 6430 mais elles sont encore peu déployées et pas étudiées ici.) Ce RFC 6650 est largement inspiré d'un document externe à l'IETF, le RFC 6449. En quelque sorte, il en est la version officielle. Les autres documents existants, comme la norme ARF (RFC 5965), sont purement techniques (définition d'un format) et ne répondent pas à des questions comme « à qui envoyer les rapports ? » ou « que faut-il mieux mettre dans un rapport ? », qui font l'objet de ce RFC. D'abord, faut-il un accord explicite du destinataire avant d'envoyer les rapports ARF ? La section 3 considère qu'il y a deux cas, celui de deux acteurs décidant entre eux de se transmettre des rapports ARF, relatifs à leurs clients. C'est le cas le plus fréquent aujourd'hui. Et le second cas est celui où des rapports non sollicités sont envoyés à quelqu'un dont l'expéditeur pense qu'il est concerné. En l'absence d'un accord préalable, ces rapports ne feront pas forcément l'objet de la même attention. La section 4 détaille le premier cas, les rapports attendus. En vrac, elle demande, entre autres : * Que l'accord entre les deux acteurs soit respecté, notamment dans le choix de l'adresse de destination (arf-feedb...@example.net, par exemple). * Que le rapport soit à la syntaxe ARF (évidemment) et que les éléments optionnels dans ARF soient inclus, s'ils sont disponibles (pas de rétention délibérée). Cela concerne Original-Mail-From, Arrival-Date, Source-IP, Original-Rcpt-To. * Pour relativiser la demande précédente, il peut y avoir occultation délibérée, pour préserver la vie privée, comme détaillé dans le RFC 6590. * Enfin, la section 4 demande (v#339;u pieux ?) que le récepteur *agisse* lorsqu'il reçoit des rapports qui le concernent (section 4.3 du RFC 6449). La section 5 s'attaque aux rapports inattendus, envoyés sans concertation préalable. Elle est bien plus longue puisqu'il s'agit d'embêter des gens qui n'ont rien demandé (dans le précédent cas, les deux parties ont pu se mettre d'accord sur tous ces points, qui doivent être explicités ici.) Les auteurs du RFC demandent, entre autres : * Que le destinataire ait un moyen de ralentir le rythme d'envoi des rapports, pour que son infrastructure ne s'écroule pas sous la charge (il n'existe pas de mécanisme standard pour cela, cela doit être fait « à la main »). * Que l'expéditeur s'assure que ses messages soient crédibles, pour diminuer le risque qu'ils soient jetés sans autre forme de procès. Cela implique notamment une authentification SPF et/ou DKIM correcte. * Que l'expéditeur soit bien conscient qu'un traitement effectif des rapports reçus a un coût pour le destinataire et qu'il fasse donc attention à produire des rapports techniquement corrects et factuellement sérieux. * Que l'expéditeur n'envoie pas automatiquement des rapports sur la base d'une analyse automatique. Les logiciels de classification peuvent se tromper et prendre pour du spam ce qui n'en est pas. Il serait anormal de générer un spam (le rapport ARF) en échange d'un message qui n'en est pas un. (Je vois au boulot pas mal de rapports violant cette règle, réalisés en format ARF ou pas, qui sont manifestement automatiquement émis par un logiciel, et un logiciel particulièrement débile en plus.) La section 5 de notre RFC recommande d'utiliser plutôt les messages
Re: [FRnOG] [TECH] Pour les utilisateurs d'ARF...
Y'avait déjà moi comment réponse, à l'époque. On l'utilise exactement comme le décrit la RFC, puisque JD Falk (R.I.P.) et Murray décrivent là la méthode la plus largement répandue pour les feedback-loop / boucles de rétro-action dont le principe est de fournir à l'expéditeur une information générée par le destinataires, dans mon cas quand un destinataire clique sur le bouton ceci es un spam. L'ARCEP devrait-elle récolter de l'information sur l'utilisation d'ARF ? Troll. Benjamin BILLON Le 26/06/2012 15:08, Stephane Bortzmeyer a écrit : Je crois que j'avais déjà demandé ici mais sans avoir de réponse. Qui utilise le format ARF, en sortie pour envoyer des rapports ou en entrée pour les analyser ? Qui l'ouvre à ses utilisateurs en leur permettant d'envoyer du ARF (explicitement ou via un formulaire) ? L'ARCEP devrait-elle récolter de l'information sur l'utilisation d'ARF ? Nouveau RFC 6650: Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF) : http://www.bortzmeyer.org/6650.html Auteur(s) du RFC: J. Falk (Return Path), M. Kucherawy (Cloudmark) Chemin des normes Le format ARF, normalisé dans le RFC 5965 permet à des acteurs de l'Internet (typiquemet des FAI et des gros hébergeurs de courrier comme Gmail) de s'envoyer des rapports structurés, produits et analysés automatiquement, au sujet des abus commis avec le courrier électronique, notamment du spam. Ce nouveau RFC du groupe de travail qui a conçu ARF expose comment et dans quelles circonstances utiliser ARF. L'idée de base d'ARF était qu'un message serait détecté comme abusif (par exemple par l'utilisateur cliquant un bouton « C'est du spam ! ») et que cette détection déclencherait l'envoi d'un rapport ARF au responsable (qui pourra le faire suivre, si nécessaire). En comparaison avec un rapport non structuré, l'avantage d'ARF est que les messages ARF seront analysables par des programmes, pour rendre leur traitement plus efficace. (Il existe des extensions à ARF pour des usages qui ne sont pas forcément des abus ou des erreurs d'authentification, comme l'extension du RFC 6430 mais elles sont encore peu déployées et pas étudiées ici.) Ce RFC 6650 est largement inspiré d'un document externe à l'IETF, le RFC 6449. En quelque sorte, il en est la version officielle. Les autres documents existants, comme la norme ARF (RFC 5965), sont purement techniques (définition d'un format) et ne répondent pas à des questions comme « à qui envoyer les rapports ? » ou « que faut-il mieux mettre dans un rapport ? », qui font l'objet de ce RFC. D'abord, faut-il un accord explicite du destinataire avant d'envoyer les rapports ARF ? La section 3 considère qu'il y a deux cas, celui de deux acteurs décidant entre eux de se transmettre des rapports ARF, relatifs à leurs clients. C'est le cas le plus fréquent aujourd'hui. Et le second cas est celui où des rapports non sollicités sont envoyés à quelqu'un dont l'expéditeur pense qu'il est concerné. En l'absence d'un accord préalable, ces rapports ne feront pas forcément l'objet de la même attention. La section 4 détaille le premier cas, les rapports attendus. En vrac, elle demande, entre autres : * Que l'accord entre les deux acteurs soit respecté, notamment dans le choix de l'adresse de destination (arf-feedb...@example.net, par exemple). * Que le rapport soit à la syntaxe ARF (évidemment) et que les éléments optionnels dans ARF soient inclus, s'ils sont disponibles (pas de rétention délibérée). Cela concerne Original-Mail-From, Arrival-Date, Source-IP, Original-Rcpt-To. * Pour relativiser la demande précédente, il peut y avoir occultation délibérée, pour préserver la vie privée, comme détaillé dans le RFC 6590. * Enfin, la section 4 demande (v#339;u pieux ?) que le récepteur *agisse* lorsqu'il reçoit des rapports qui le concernent (section 4.3 du RFC 6449). La section 5 s'attaque aux rapports inattendus, envoyés sans concertation préalable. Elle est bien plus longue puisqu'il s'agit d'embêter des gens qui n'ont rien demandé (dans le précédent cas, les deux parties ont pu se mettre d'accord sur tous ces points, qui doivent être explicités ici.) Les auteurs du RFC demandent, entre autres : * Que le destinataire ait un moyen de ralentir le rythme d'envoi des rapports, pour que son infrastructure ne s'écroule pas sous la charge (il n'existe pas de mécanisme standard pour cela, cela doit être fait « à la main »). * Que l'expéditeur s'assure que ses messages soient crédibles, pour diminuer le risque qu'ils soient jetés sans autre forme de procès. Cela implique notamment une authentification SPF et/ou DKIM correcte. * Que l'expéditeur soit bien conscient qu'un traitement effectif des rapports reçus a un coût pour le destinataire et qu'il fasse donc attention à produire des rapports techniquement corrects et factuellement sérieux. * Que l'expéditeur n'envoie pas automatiquement des rapports sur la
[FRnOG] [TECH] Rapport sur la résilience de l'Internet en France
http://www.bortzmeyer.org/rapport-resilience-internet-france.html Hier a vu la publication du premier « Rapport sur la résilience de l'Internet en France http://www.ssi.gouv.fr/fr/menu/actualites/l-anssi-et-l-afnic-publie-un-etat-des-lieux-de-l-internet-francais.html ». Il s'agit d'étudier *quantitativement* la résilience de l'Internet dans ce pays (oui, je sais, l'Internet est mondial, mais il faut bien commencer quelque part). Le rapport définit donc un certain nombre d'indicateurs puis les mesure et publie le résultat. Le rapport est un travail commun de l'ANSSI et de l'AFNIC. Il comprend deux grandes parties, une sur le protocole BGP et une sur le DNS. Dans le futur, d'autres protocoles pourront être étudiés. Espérons que cette édition 2011 sera suivie de bien d'autres. Ce travail a déjà été présenté (en anglais) à une réunion OARC http://www.bortzmeyer.org/oarc-londres-resilience.html (supports disponibles). Il sera évoqué rapidement au prochain Frnog http://frnog.org/?page=frnog19 et surtout à la Journée du Conseil Scientifique de l'AFNIC http://www.afnic.fr/fr/l-afnic-en-bref/actualites/actualites-generales/6083/show/journee-du-conseil-scientifique-de-l-afnic-le-4-juillet-2012-3.html le 4 juillet. Sinon, sur la résilience, j'ai déjà fait un article http://www.bortzmeyer.org/eteindre-internet.html. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Étiquetage des cables en datacenter
Hello, Le 26/06/2012 0:56, Jean-Edouard Babin a écrit : En version pas cher tu as ce genre de chose http://www.aliexpress.com/product-gs/289949747-Free-shipping-by-China-Air-Post-200-RJ45-RJ11-RJ12-Color-Numeric-Cable-Label-Mark-8002-wholesalers.html Cela on l'air assez pourri, Il y en a des bien mieux adapté pour câble ethernet avec un système pour pouvoir les poser simplement par contre je ne connais pas la marque L'avantage: ca coute pas cher, tu peux en avoir un peu partout plutôt que de courir après la dymo (ou autre), si tu as une grosse densité de câble et que les numéros ne sont pas visible tu as toujours le code couleur visible (alors que si tu vois pas ton étiquette, t'es mal..) Clairement c'est le clone chinois (ou pas) de ce qu'il se fait chez Legrand (il faut chercher sur le catalogue). J'utilisais ce genre de chose chez ISDnet (souvenir...). Seul inconvénients : - c'est un long à mettre en place - c'est de fois relou vis à vis de la souplesse du câble - pour les FO, c'est des fois moyen Dernier point comme tout étiquetage, reste à trouver les désignation idéales à mettre dessus... /Xavier -- Xavier Beaudouin --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] L'Internet est-il résilient ? Le sera-t-il plus ou moins ?
Vous êtes tous cordialement invités à la Journée du Conseil Scientifique de l'AFNIC (oui, l'AFNIC mais il y aura quand même beaucoup de BGP dedans) qui se tient le 4 juillet à Paris et qui est suivie d'un cocktail (comme pour Frnog 19 :-) C'est gratuit mais faut s'inscrire, nombre de places limité. Le thème est « L'Internet est-il résilient ? Le sera-t-il davantage ? Ou moins ? » Le programme complet et les détails sont là : http://www.afnic.fr/fr/l-afnic-en-bref/actualites/actualites-generales/6076/show/journee-du-conseil-scientifique-de-l-afnic-le-4-juillet-2012.html --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Rapport sur la résilience de l'Internet en France
Le 2012-06-26 09:38, Stephane Bortzmeyer a écrit : http://www.bortzmeyer.org/rapport-resilience-internet-france.html Hier a vu la publication du premier « Rapport sur la résilience de l'Internet en France http://www.ssi.gouv.fr/fr/menu/actualites/l-anssi-et-l-afnic-publie-un-etat-des-lieux-de-l-internet-francais.html ». Bravo pour ce rapport qui est très exhaustif sur les points qu'il aborde. Pour autant j'ai l'impression qu'il manque un point essentiel. Internet, c'est avant tout des tuyaux, des fibres et du cuivre. La résilience doit être d'abord et avant tout topologique et géographique. Étudier le nombre de peering et les contrats de trafic des AS est intéressant, mais si tout se fait dans un seul IX à Paris, il n'y a aucune résilience. Une fibre qui lâche, une arrivée électrique qui tombe et c'est le drame. A mon sens, il aurait fallut réfléchir ainsi Si Paris est dévastée par une bombe nucléaire, combien d'AS tiennent encore debout ? La réponse est : très peu. Très peu d'AS peerent en région, très peu ont délocalisé en province ou à l'étranger des systèmes vitaux redondants. Et puis Internet ce n'est pas que les AS et les backbones, ce sont aussi les paires de cuivre ou les fibres qui amènent les IP publiques jusque dans les foyers. Un lien backbone lâche, plusieurs centaines de DSLAM qui tombent, cela fait combien de foyers déconnectés ? Internet dans son entièreté n'est pas si résilient que ça. Souvent ça ne tient qu'à un fil. ;) Cordialement. -- Raphaël Durand www.ultrawaves.net Cet e-mail est protégé par les lois françaises sur le secret de la correspondance. Les mails postés depuis cette boite personnelle n'engagent en aucune façon mon employeur. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Rapport sur la résilience de l'Internet en France
Le 26/06/12 17:23, Bruno CAVROS / SKIWEBCENTER a écrit : En cas de conflit (ou même guerre économique ? ) il ne faudra plus compter sur les réseaux filaires qui seront immédiatement détruits... Bonjour, heureusement, il y a commotion pour ce jour là : http://fr.wikipedia.org/wiki/Commotion ;-) Cordialement, Eric ROLLAND Réseau Artewan AS42929 ORG-ARTE2-RIPE *Artefact communication interactive* | Bat. Artechnopole - 3 rue des Frères Goncourt - 19100 BRIVE | Tel 0555 17 29 29 | Fax 0957 33 00 33 SARL au capital de 50.000 Euros - RCS BRIVE 444 110 936 | NAF 7311Z | TVA Intracom FR87444110936 www.artefact.fr http://www.artefact.fr - Communication interactive www.artewan.fr http://www.artewan.fr - Opérateur de réseaux *Découvrez Artechnopole http://www.artechnopole.fr, un espace IT de 380 M2, intégrant un Datacenter climatisé, ondulé et secouru. * --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] equivalent de l'APC ATS avec reboot control par outlet
Bonjour, Je me demandais si l'un d'entre vous avez vu l'equivalent en terme de forme (rackable, 1U) des ATS APC (www.apc.com/products/family/?id=14) avec possibilite de controle d'alimentation individuel des ports? requis: Dual source, C14 ou C20 input, C13 output. - reboot snmpable. Merci de vos (eventuelles) lumieres. Jean --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] equivalent de l'APC ATS avec reboot control par outlet
Hello, renseignes toi chez up440.com, IPSO Switcher. C'est modulaire et tu as du SNMP... pour le reste, à voir. Et c'est made in France ! -- Florian VANNEROY Sysadmin ELB Group www.netissime.com Le 26/06/12 17:48, Jean Barbezat a écrit : Bonjour, Je me demandais si l'un d'entre vous avez vu l'equivalent en terme de forme (rackable, 1U) des ATS APC (www.apc.com/products/family/?id=14) avec possibilite de controle d'alimentation individuel des ports? requis: Dual source, C14 ou C20 input, C13 output. - reboot snmpable. Merci de vos (eventuelles) lumieres. Jean --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Rapport sur la résilience de l'Internet en France
Le 26 juin 2012 17:27, Eric ROLLAND roll...@artefact.fr a écrit : Le 26/06/12 17:23, Bruno CAVROS / SKIWEBCENTER a écrit : En cas de conflit (ou même guerre économique ? ) il ne faudra plus compter sur les réseaux filaires qui seront immédiatement détruits... Bonjour, heureusement, il y a commotion pour ce jour là : http://fr.wikipedia.org/wiki/Commotion ;-) vivent les ondes non soumises à la pelleteuse, incendie... On rigole avec nos antennes, mais elles rendront bien service quand les toyos lacheront... -- PR/FFW --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] Rapport sur la résilience de l'Internet en France
On Tue, Jun 26, 2012 at 05:09:59PM +0200, Raphaël Durand raphael.dur...@ultrawaves.net wrote a message of 48 lines which said: Pour autant j'ai l'impression qu'il manque un point essentiel. Internet, c'est avant tout des tuyaux, des fibres et du cuivre. La résilience doit être d'abord et avant tout topologique et géographique. Je ne suis pas sûr d'être d'accord, surtout avec le « avant tout ». Il y a deux raisons pour lesquelles le rapport ne contient pas de mesures sur la résilience physique (celles des câbles) : 1) Nous n'avons pas l'information. Il faudrait que l'ANSSI ou l'ARCEP (oui, je trolle un peu) obligent les opérateurs à la donner, pour qu'on puisse se faire une idée de la résilience physique. Les clients de Prosodie à Vélizy auraient bien aimé savoir que les trois fibres passaient en fait dans la même tranchée, mais cette information n'est pas publique, pas facile à trouver et pas mesurable automatiquement à distance. 2) À l'échelle de tout l'Internet (mais pas à celle d'un service particulier), la résistance aux pannes physiques est grande, comme l'avait montré le séisme de mars 2011 http://archive.psg.com/111206.conext-quake.pdf. On ne peut pas espérer planter tout l'Internet avec une action physique (ou alors, il en faudrait beaucoup, réparties à plein d'endroits). En revanche, une attaque exploitant une faille premier jour sur IOS *et* JunOS a, en théorie, cette possibilité. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] Rapport sur la résilience de l'Internet en France
On Tue, Jun 26, 2012 at 05:23:44PM +0200, Bruno CAVROS / SKIWEBCENTER br...@skiwebcenter.fr wrote a message of 92 lines which said: En cas de conflit (ou même guerre économique ? ) il ne faudra plus compter sur les réseaux filaires qui seront immédiatement détruits... Le rapport ne se place pas tellement dans l'hypothèse d'une invasion chinoise ou nord-coréenne (on entre dans une autre catégorie de problèmes). Déjà, si on pouvait résister aux incidents quotidiens (« fat fingering » d'un opérateur tapant sa config', panne électrique d'un datacenter), ce serait pas mal. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Rapport sur la résilience de l'Internet en France
On 06/26/2012 09:38 AM, Stephane Bortzmeyer wrote: http://www.ssi.gouv.fr/fr/menu/actualites/l-anssi-et-l-afnic-publie-un-etat-des-lieux-de-l-internet-francais.html ». Il s'agit d'étudier*quantitativement* la résilience de l'Internet dans ce pays (oui, je sais, l'Internet est mondial, mais il faut bien commencer quelque part). Le rapport définit donc un certain nombre d'indicateurs puis les mesure et publie le résultat. J'aurais trouvé utile de fournir une formule mathématique à appliquer sur les paramètres de son propre AS, histoire de ne pas avoir besoin de prendre rendez-vous avec ANSSI pour savoir si oui ou non, le dit AS est suffisamment connecté, et se comparer aux exemples d'AS donnés dans le rapport. Je reconnais qu'il y a une contradiction entre le besoin d'anonymiser les AS tout en fournissant un moyen de mesure, parce qu'il n'y a que 163 AS français et que les données utilisées par le rapport sont publiques. Si la mesure est bien choisie, il y a peu de chance pour que deux AS aient au final, la même mesure dans seulement 163 AS. Qui dit mesure, dit étalon, je serais curieux de connaitre la description de l'AS étalon par l'ANSSI, pour que chacun puisse mesurer la distance qui le sépare cet AS (et donc connaitre les efforts à fournir, ou de se dire ouf, je suis bon). --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] Rapport sur la résilience de l'Internet en France
On Tue, 26 Jun 2012 17:23:44 +0200, Bruno CAVROS / SKIWEBCENTER br...@skiwebcenter.fr said: En cas de conflit sur le territoire national, l'Internet c'est le moindre de tes problemes --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] Rapport sur la résilience de l'Internet en France
Oui fin internet.. telephonie... tu crois que le téléphone du préfet passe encore par FT ? Je peux te citer en exemple d'une préfecture raccorder via com** via une DSP ** ou l'opérateur co** héberge son équipement réseau dans le POP de cette même DSP sur une prise 220V direct EDF ! sans même un onduleur... Du coup quand ça coupe la préfecture sans le moindre backup est à l'arrêt sans moyens de communications :) bah moi je dis... ça fait froid dans le dos en cas de gros sinistre, tempete et j'en passe :) Pour l'heure les coupures d'internet c'est à 95% des problèmes hardware ou physique (fibercut, panne d'énergie), pas venant de BGP ... -Message d'origine- De : Radu-Adrian Feurdean [mailto:fr...@radu-adrian.feurdean.net] Envoyé : mardi 26 juin 2012 22:11 À : Bruno CAVROS / SKIWEBCENTER; 'Raphaël Durand'; frnog@frnog.org Objet : RE: [FRnOG] [TECH] Rapport sur la résilience de l'Internet en France On Tue, 26 Jun 2012 17:23:44 +0200, Bruno CAVROS / SKIWEBCENTER br...@skiwebcenter.fr said: En cas de conflit sur le territoire national, l'Internet c'est le moindre de tes problemes --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Switch
Arf, plutôt moche ... surtout pour le SNMP. Il est quasi sur que la gamme SG500 des Cisco Small Business répondrait à tes besoins. Surement un peu plus que nécessaire, vu que si tu les configure pour, ils sont N3, reste à voir le budget. J'ai encore quelques interrogations dessus , mais je vais poster un nouveau sujet pour ca. @+ Christophe. Jérémy Martin a écrit : Sur la série 300, c'est d'office maintenant. Sur la série 200 qu'on a actuellement, y a même pas de cable série donc bon... Là, en dehors du CLI, il nous manque le SNMP, tellement important pour superviser le réseau qu'on a décidé de tout changer malgré le cout prohibitif... Cordialement, Jérémy Martin Le 24/06/2012 23:14, Arnaud Launay a écrit : Le Sun, Jun 24, 2012 at 07:51:17PM +0200, Christophe a écrit: Les SF300 qu'on a en production n'en ont pas non plus , mais le dernier en date installé en a un . Une petite mise à jour pour l'activer ? Oui, ça a été mis en place par un firmware de fin novembre 2011, je crois. Les derniers neufs qu'on a reçu avaient déjà un firmware à jour et la CLI active par défaut, avec le câble série qui va bien. Arnaud. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] Cisco Small Business SG gamme 500 et IPv6
Bonjour à tous , Afin d'équiper notre future baie, et ayant une certaine expérience de la gamme cisco Small Business, nous souhaiterions utiliser la (toute nouvelle) gamme SG 500 de chez Cisco Small Business . De part et d'autre, notamment de notre fournisseur de ces produits, l'expression full ipv6 est apparue . Après parcours des docs, et en particulier de l'Admin guide, j'ai quelques doutes sur la susdite expression : De ce que j'en ai vu, cette gamme ne fait ni plus ni moins ce que faisait la gamme SGE20x0/SFE20x0 avec quelques RFC en plus. La précédente gamme était dite IPv6 , bien beau sur le papier, mais en fait , seul l'accès au switch pouvait l'être : une seule et unique interface physique ou virtuelle configurable en v6, et donc d'un intérêt très contestable ... La nouvelle datasheet, fait un tout aussi beau discours , mais rien qui ne me fait penser que ca puisse répondre au besoin. Il n'est rien demandé de plus que du routage inter-vlan en v6 et du RA pour chaque VLAN configuré en v6 (DHCPv6 relay serait un plus, mais il ne faut peut être pas être trop ambitieux non plus ... ). Donc je demande au gens qui savent , et non aux commerciaux qui n'y pigent pas toujours grand chose. Quelqu'un a t'il un des modèles de la gamme 500 en test ou en prod , qui peut m'assurer que plusieurs interfaces IPv6 peuvent y être configurées , que le routage inter-vlan peut s'opérer dessus, et qu'il est possible de paramétrer les fameuses interfaces pour attribuer de l'IPv6 en stateless ? Ou eventuellement, quel produit équivalent en terme de tarifs peut le faire ? Bonne fin de soirée :) . Christophe. --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] Rapport sur la résilience de l'Internet en France
Le mardi 26 juin 2012 à 22:11 +0200, Radu-Adrian Feurdean a écrit : On Tue, 26 Jun 2012 17:23:44 +0200, Bruno CAVROS / SKIWEBCENTER br...@skiwebcenter.fr said: En cas de conflit sur le territoire national, l'Internet c'est le moindre de tes problemes ;) mh --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Rapport sur la résilience de l'Internet en France
Bonsoir, Je trouve le rapport très intéressant et pas mal pour une première étude car déjà c'est pas évident de traiter le sujet et de choisir des indicateurs servant à une étude quantitative: Voici quelques points que j'ai pu remarqués: 1. Je m’attendais à un des indicateurs classiques mesurant le Down Time: MTBF, MTTR == Mais, j'imagine que cela nécessite un accès à des données confidentielles. 2. Le rapport est basé sur des donnée publiques. Donc tout ce qui est architecture (physique, logique) plus ou moins détaillée est évidemment confidentiel et sera bien protégé par chaque opérateur et je pense que si un jour on jugera que des indicateurs se basant sur des documents confidentiels devront être utilisé le Rapport même sera CONFIDENTIEL et on ne sera pas là entrain d'en discuter. 3. L'indicateur Usurpation d'identité: deux remarques : * Le contre: IL n'a pas servi à grand chose surtout de point de vue résilience d'internet le sujet d’étude car tout ce qui apparait comme usurpation était en vrai des faux positifs. * Le pour: Encore faut il y penser et vérifier que c’est des faux positifs chose qui n’était pas évidente au départ j’imagine bien. En plus, cela a permis de pointer une pratique pas trop conforme concernant la déclaration des Objets Routes. 4. le choix du protocole du routage BGP comme indice est très réussi. Il est juste utilisé comme INDICE, dans ce sens la couche trois reflètera bien l'état même de la couche physique/Hardware car une panne de ce genre affectera, entre autre, la table de routage. Donc le niveau trois sert d'indice globale (niveau 1, 2, et 3). Par contre, ce n'est pas et ne doit pas être le seul indice. 5. Le but de l'étude est d'avoir un état de lieu actuel (plus précisément sur 11 mois de 2011) de la résilience de l'internet français. Donc plutôt une étude rétrospective (très récente). Il ne s'agit pas de faire une ANALYSE DES RISQUES et donner des recommandations en conséquence. Par contre, cela pourrait faire l'objet d'une autre étude et sera très intéressant comme sujet. Après il faudra aussi savoir rationaliser et prioriser les scénarios d'une étude des risques. 6. Un réseau Wireless qui connecte tout et qui résistera aux catastrophes c'est bien mais d'une part ça n'atteindra pas la même qualité qu'un réseau filaire. Et puis faudra penser aussi aux risques sanitaires de vivre dans une micro-onde. 7. Ça sera intéressant de savoir jusqu'à où les opérateurs et AS coopéreront en cas du besoin ? Sujets chauds: données confidentielles, image et qualité de service (SLA) en jeu ..? Bien cordialement, De : Bruno CAVROS / SKIWEBCENTER br...@skiwebcenter.fr À : 'Radu-Adrian Feurdean' fr...@radu-adrian.feurdean.net; 'Raphaël Durand' raphael.dur...@ultrawaves.net; frnog@frnog.org Envoyé le : Mardi 26 juin 2012 22h31 Objet : RE: [FRnOG] [TECH] Rapport sur la résilience de l'Internet en France Oui fin internet.. telephonie... tu crois que le téléphone du préfet passe encore par FT ? Je peux te citer en exemple d'une préfecture raccorder via com** via une DSP ** ou l'opérateur co** héberge son équipement réseau dans le POP de cette même DSP sur une prise 220V direct EDF ! sans même un onduleur... Du coup quand ça coupe la préfecture sans le moindre backup est à l'arrêt sans moyens de communications :) bah moi je dis... ça fait froid dans le dos en cas de gros sinistre, tempete et j'en passe :) Pour l'heure les coupures d'internet c'est à 95% des problèmes hardware ou physique (fibercut, panne d'énergie), pas venant de BGP ... -Message d'origine- De : Radu-Adrian Feurdean [mailto:fr...@radu-adrian.feurdean.net] Envoyé : mardi 26 juin 2012 22:11 À : Bruno CAVROS / SKIWEBCENTER; 'Raphaël Durand'; frnog@frnog.org Objet : RE: [FRnOG] [TECH] Rapport sur la résilience de l'Internet en France On Tue, 26 Jun 2012 17:23:44 +0200, Bruno CAVROS / SKIWEBCENTER br...@skiwebcenter.fr said: En cas de conflit sur le territoire national, l'Internet c'est le moindre de tes problemes --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
