Re: [FRnOG] [MISC] Peering Nerim ?
Hi, C’est bien peer...@nerim.net :) Je recommande toutefois de vérifier sur nos stats publiques (https://stats.nerim.net/) en entrant le numéro d’AS que le trafic justifie une session directe (nous privilégions les RS, sauf pour les peerings à fort trafic.) -- Antoine Versini - Nerim > Le 7 sept. 2017 à 17:00, David Ponzone <david.ponz...@gmail.com> a écrit : > > peer...@nerim.net non ? > Ca répond pas ? > Antoine ? :) > > > Le 7 sept. 2017 à 16:04, Julien Escario a écrit : > >> Salut la liste, >> A priori, la peering policy de Nerim est 'selective' et je ne trouve >> personne à >> qui envoyer une demande. >> >> Y'a t'il un qqun de chez AS13193 qui lirait la liste et pourrait envisager >> une >> ou plusieurs sessions avec mon petit AS41405 ? J'ai AMS-IX, EQX Paris et >> France-IX en commun, ça serait dommage de ne pas en profiter. >> >> Merci ! >> Julien >> > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] comparatif *technique* des FAI "grand public"
> Le 23 août 2017 à 19:40, Eric Belhomme <rico-fr...@ricozome.net> a écrit : > > Bah, j'ai bien pensé à Nerim, mais mes dernières expériences professionnelles > avec eux m'ont un peu fait déchanter : excellence technique des années 2000 > est partie en même temps que son fondateur :( Hello, Je suis curieux, navré qu’il vous soit arrivé des mésaventures. Vous pourriez m’en dire plus, svp ? En privé si vous voulez. -- Antoine Versini - Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] The Death of Transit and Beyond
> Le 13 mars 2017 à 11:03, David Ponzone <david.ponz...@gmail.com> a écrit : > > Votre discussion m’amène à me poser une question: est-ce que quelqu’un a une > idée de l’ARPU moyen supplémentaire qu’un FAI (implicitement gros) dégage de > son propre contenu qui lui a coûté tellement d’efforts et d’argent à déployer > ? > On parle de 5% de l’abo mensuel (donc 3-4€), 10, 20, 30 % ? moins de 5 ? Donnée ultra-sensible. Dis-toi juste que chez certains, la connectivité Internet peut être (plus ou moins) en rade pendant des heures sans que cela ne les inquiète outre mesure, alors que si la TV est coupée plus de 5 minutes c’est tout le monde sur la brèche, même en pleine nuit. -- Antoine Versini - Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Le troll du vendredi
> Le 10 mars 2017 à 11:41, Clement Cavadore <clem...@cavadore.net> a écrit : > > Cette mailing liste, on y reste abonné (ou pas) plus par habitude que > par intérêt (ou éventuellement pour "ne pas rater une info qui pourrait > passer"). C'est dommage (et ca se ressent dans le genre de public qu'on > retrouve aux meetings, au passage). Que dire de mieux, Clément a parfaitement résumé la situation. -- Antoine Versini - Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Problème sur NRA 75110NOR
> Le 13 févr. 2017 à 15:01, David Ponzone <david.ponz...@gmail.com> a écrit : > > Ca a commencé un peu avant midi, rétabli peu après, et c’est retombé encore. > Les SDSL et ADSL sont concernés à priori. You sure ? swr401-nra-nord-jemmapes#sh log | i Feb 13 swr401-nra-nord-jemmapes#sh hard | i uptime swr401-nra-nord-jemmapes uptime is 4 years, 47 weeks, 5 days, 2 hours, 46 minutes -- Antoine Versini - Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] Re: Bientôt le week-end, un débat sur l'adressage des routeurs
> Le 23 juil. 2016 à 20:02, Michel Py <mic...@arneill-py.sacramento.ca.us> a > écrit : > > C'est vrai, mais il y a bien des cas ou c'est une excuse facile. Ce qu'on > fait en ce moment, c'est rajouter une couche de peinture sur la merde pout > que çà ait l'air propre du coté client, pas de faire des choses propres. Je > critique pas, j'essaie d'être réaliste. > > Michel. Pour un client qui ne comprenait pas voir l’adressage des LSR du backbone en IP publique dans les traceroutes sur son VPN MPLS (en adressage privé) je me suis résolu à les masquer. Cela évite aussi au passage le sempiternel gus qui vient te démontrer par A+B que tu as du loss sur ton réseau quand tes LSR font de la limitation d’ICMP unreachables, alors que son « mtr » montre bien évidemment 0,0% de pertes au dernier saut. -- Antoine Versini - Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Coupures NERIM ?
Le 12 févr. 2015 à 11:58, Sylvain Donnet sylvain.don...@ddo.net a écrit : Bonjour, J’ai une FO client down sur Toulouse, et une SDSL down sur Bordeaux. Ca, c’était avant 11h30. C’était revenu, et c’est reparti… Pb global chez Nerim ? Le support est injoignable en ce moment, je suis sur leur messagerie vocale depuis 15mn. Certains de nos raccordements de collecte régionale (notamment dans les deux villes que vous mentionnez) se sont mis à recevoir une quantité importante de trafic. Les mécanismes de protection ont empêché l'inflation du trafic, mais la saturation entrante vers notre réseau n'en a pas moins demeuré, sans aucune hausse de sortant par ailleurs. Il ne s'agit pas d'un problème lié à un plantage d'équipement dans notre réseau, et il n'y avait pas d'opération en cours. -- Antoine Versini - Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Raccordement fibre optique Courbevoie
Le 9 févr. 2015 à 11:45, David Ponzone david.ponz...@gmail.com a écrit : Si tu veux une offre Grand Public (appelez honteusement Pro par certains), il va falloir qu’il y ait pas mal d’autres clients potentiels à la même adresse pour motiver un opérateur de venir, et encore…tu peux tenter la pétition :) Salut David, Pour bénéficier d'un service GP adapté pro dans un immeuble de bureaux, il faut que cet immeuble soit considéré comme mixte. C'est-à-dire qu'une partie soit occupée par du résidentiel. Sinon les divisions GP des OBL FTTH/FTTLA qui sont en charge de ces déploiements n'auront même pas l'immeuble dans leur radar, et il ne sera donc possible de le faire percuter que pour du CELAN-like ou FON opérateur. C'est donc souvent l'inverse qui s'applique: ce sont des immeubles d'habitation partiellement reconvertis occupés par des (petites) entreprises qui sont éligibles à ce type de raccordements. -- Antoine Versini - Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Nerim is dead ?
Le 2 déc. 2014 à 13:13, Antoine Versini antoine.vers...@corp.nerim.net a écrit : Un ticket constructeur va être ouvert, et je ferai un follow-up avec la raison du plantage. Comme promis, l'épilogue. Il s'agit d'un problème connu chez le constructeur de nos routeurs de service lié à l'utilisation de BGP Flowspec. Ce problème avait déjà été corrigé sur d'autres trains logiciels, mais pas encore intégré dans celui que nous utilisons (notre version de production étant pourtant datée courant 2014.) L'intégration du correctif dans notre train va être réalisée, dans l'intérim nous savons comment éviter qu'il se reproduise (mais pas encore pourquoi il s'est toutefois produit qu'après 14 mois d'utilisation.) J'en profite pour remercier leurs équipes SE, commerciales, support et ingénierie qui ont été très promptes et efficaces pour comprendre et tâcher de résoudre nos problèmes. Ils se reconnaîtront ;-) -- Antoine Versini - Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Nerim is dead ?
Le 2 déc. 2014 à 11:59, Christophe t...@stuxnet.org a écrit : Bonjour, Il semblerait que cela soit retombé (11h53) , symptômes identiques . Bonjour, Le problème n'est pas le même, nous n'avons pas perdu massivement nos sessions eBGP. Cette fois-ci il s'agit du plantage du processus de routage (rpd) sur un routeur qui accueille un lien de transit assez important. Cela a provoqué une instabilité dans le routage des destinations de la DFZ ainsi que des perturbations sur les services d'hébergement, connectivité et collecte transitant par nos DC à St-Denis. La machine n'assurait plus ses tâches de routage de façon permanente, continuait à s'annoncer comme passerelle à d'autres routeurs alors qu'elle était incapable d'assurer le routage vers les destinations. Cela donne (heures UTC) : Dec 2 10:51:11 edg-sde-3 /kernel: pid 1404 (rpd), uid 0: exited on signal 11 (core dumped) Dec 2 10:51:11 edg-sde-3 init: routing (PID 1404) terminated by signal number 11. Core dumped! Dec 2 10:51:11 edg-sde-3 /kernel: edg-sde-3 init: routing (PID 1404) terminated by signal number 11. Core dumped! Dec 2 10:51:11 edg-sde-3 init: routing (PID 84024) started Un ticket constructeur va être ouvert, et je ferai un follow-up avec la raison du plantage. -- Antoine Versini - Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Nerim is dead ?
Le 21 nov. 2014 à 09:00, Clement Cavadore clem...@cavadore.net a écrit : Je sens que nos amis de Junipe(u)r vont encore en prendre pour leur grade... Il serait intéressant de savoir exactement ce qui s'est passé (en privé, si tu préfères), pour la culture. Hello Clément, Je n'ai pas l'intention de jeter l'opprobre sur un constructeur ou l'autre. Nous ne pratiquons pas ce type de communication. D'autant plus que pour le moment la seule chose apparente se sont des messages assez laconiques dans les journaux qui indiquent des pertes simultanées de sessions eBGP dans *une seule VRF* (la pire, certes) sur un bon nombre de machines et sans action associée. Tous nos partenaires de peerings ont pu s'en apercevoir ;) See you! -- Antoine Versini - Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Nerim is dead ?
Le 20 nov. 2014 à 16:57, Eddy Minet eddy.mi...@rsi-informatique.fr a écrit : Bonjour, L'opérateur Nerim viendrait-il de disparaitre de l'Internet ? Tous nos clients Nerim sont dans le rouge et leur site Web injoignable ... Bonsoir, Je confirme que nous avons rencontré un problème dans la VRF qui porte les routes Internet. Nous en cherchons la cause, mais nous savons déjà que l'origine n'est pas un changement de configuration d'un équipement, aucun commit ou clear quelconques n'ayant été effectués pendant les heures avant l'évènement. (Nous excluons donc l'erreur humaine.) Le plus gros de la coupure est liée au temps de re-convergence des PE portant la production des services faisant usage des routes de la DFZ d'Internet. -- Antoine Versini - Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Philippe Bourcier, la fibre au bureau
Le 18 août 2014 à 20:55, Thierry Martin (Europe) thierry.mar...@dimensiondata.com a écrit : Monsieur Philippe Bourcier = trouvez-vous sur le commerce des PCs (et pas des serveurs) avec un port FO ou un slot pour un GBIC type SFP (nouvelle génération) ?? = alors, réfléchissez avant d'écrire vos articles. Bonjour Monsieur (Europe) Martin Thierry, Je ne suis pas certain que cracher à la figure du fondateur de FRnOG, dans sa propre mailing-list, soit la façon la plus avisée (d'essayer) de donner la moindre crédibilité à vos propos… -- Antoine Versini - Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Philippe Bourcier, la fibre au bureau
Le 19 août 2014 à 11:40, Philippe Bourcier phili...@frnog.org a écrit : - on a préféré limiter les users à 100M (le même switch existe en 8 ports Gig), car le luser n'a pas besoin de plus, étant le cul sur le backbone, si par ex. un dev se met à transférer un truc sur un serveur de prod en Gig, alors il peut défoncer l'uplink du serveur et créer un incident de prod sans même s'en rendre compte... en 100M, il faut qu'ils s'y mettent à 10, c'est déjà plus compliqué :) Sans parler de ce qu'un PC infecté (et y en a plusieurs centaines) peut faire niveau DoS avec une telle puissance de frappe... donc autant éviter les ennuis, la meilleure QoS restant celle qu'on n'a pas à appliquer (copyright François Colombaro) :) Salut Philippe, Merci pour ton explication super claire ! Chez nous j'ai tenté le free-for-all pour les end-stations utilisateurs : tout le monde en GE, upstreams 10G (pour moins de 100 personnes, dont des devs/ingés/admins friands de BP.) Tu te rends compte que comme les transferts durent beaucoup moins longtemps, ils ne se superposent pas et paradoxalement créent un encombrement moindre sur tes upstreams. A+ -- Antoine Versini - Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Cisco 7600 - 3BXL - incident 12/08 à 09h50
Le 14 août 2014 à 15:19, Fedotova, Claire Svetlana Four claire.f...@colt.net a écrit : Bonjour, Comme disent certaines sources faisons transpirer les commerciaux ...de Cisco? :) Ok, je sors Petit coucou à A.V. :) Salut Claire :) J'ai transformé ces bidules en multiprises MPLS depuis un bail ici, bon courage à ceux qui vont essayer de faire transpirer un commercial Cisco avec leurs antiquités… A+ -- Antoine Versini - Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Netflix in France
Le 27 juil. 2014 à 11:49, Greg Villain fr...@tadcons.net a écrit : Sur ce je vais me coucher, j’ai barbecue demain. Un barbecloud ? --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [tech] coupure voltaire
Le 7 juil. 2014 à 17:44, Xavier Lemaire xav...@zelites.org a écrit : Bonjour, Je viens de voir ds coupure chez TH2 à voltaire? Des infos ? durée 5 minutes tout est up pour nous Bonsoir Xavier, Nous avons effectivement eu une coupure de quelques minutes avec nos peers au SFINX. Typiquement le trafic avec OVH ou SFR a été perturbé le temps de la re-convergence. Salutations. -- Antoine Versini - Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] calcul du temps d'émission adsl vs fibre
Le 10 avr. 2014 à 21:51, David Ponzone david.ponz...@gmail.com a écrit : Les nouveaux entrants (OVH ou Nerim) par exemple ont pu directement prendre des DSLAM GE. Bonjour David, Je me permets d'apporter une précision à ce stade. Le type d'interface upstream du DSLAM (Ethernet ou ATM) ne conditionne pas le niveau 2 d'une liaison DSL. Sur nos DSLAM, je peux faire indépendamment de l'ATM ou du PTM/EFM sur les liaisons qui le permettent. La matrice des possibilités est la suivante : - ADSL/ADSL2+ : layer 2 ATM. La couche SAR ré-assemble les trames Ethernet PPPoE avant de les bridger sur l'upstream GE. - VDSL2 : layer 2 ATM ou PTM au choix. Dans le cas ATM, cela se comporte comme de l'ADSL2+, dans l'autre le 802.3ah est bridgé en Ethernet classique vers l'upstream (avec éventuellement les stacks de tag nécessaires.) - SDSL/g.SHDSL.bis : idem VDSL2. Evidemment, sur les boucles métro l'ensemble du trafic est en Ethernet. -- Antoine Versini - Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] calcul du temps d'émission adsl vs fibre
Le 11 avr. 2014 à 11:09, David Ponzone david.ponz...@gmail.com a écrit : Ca fait un baille! 15 ans, si je ne me trompe. Dino time ! Et EFM sur DSLAM ATM ? Ca doit pas être impossible, mais relativement dénué d'intérêt, donc j'imagine que c'est pour ceci qu'Orange semble attendre qu'un DSLAM soit GE avant de proposer l'EFM. Oui je présume que d'un point de vue purement ingénierie c'est faisable, en inversant le positionnement de la couche SAR dans le chemin de donnée au sein du DSLAM. Si la carte de ligne supporte donc de recevoir du PTM/EFM sur un port DSL, elle encapsule dans de l'AAL5 les trames et les fais suivre dans un VP/VC sur l'upstream. Tiens, puisque je t'ai sous la main, est-ce que tu peux me dire si vos DSLAM ont un paramètre côté SDSL qui permet de forcer le type d'Annex négocié avec le CPE, indépendamment de ce que le CPE a comme config. Par exemple, CPE configuré en Annex G, et malgré tout le lien monte en Annex B. J'ai eu un cas comme ça chez Orange, et évidemment, ça ne le fait pas à chaque fois (sur un autre lien, ça ne monte pas du tout si je ne mets pas Annex B), donc je suspecte une variabilité de conf sur le DSLAM. Oui je te confirme que certains profils (surtout les bas débits) sont fixés en Annex B / 16-TCPAM alors que tout ce qui va nécessiter entre 2 et 5Mbit/s par paire sera forcé en Annex G / 32-TCPAM. Si tu as des besoins spécifiques, on peut poursuivre en privé :) -- Antoine Versini - Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] calcul du temps d'émission adsl vs fibre
Le 11 avr. 2014 à 18:09, Michel Py mic...@arneill-py.sacramento.ca.us a écrit : Antoine Versini a écrit: La matrice des possibilités est la suivante : - ADSL/ADSL2+ : layer 2 ATM. La couche SAR ré-assemble les trames Ethernet PPPoE avant de les bridger sur l'upstream GE. Ne connaissant pas tes DSLAM, je ferai remarquer qu'ici on voit pas mal d'aDSL / aDSL2+ qui n'a PAS de PPPoE/PPPoA et utilise directement RFC1483 bridging (maintenant RFC2684) à la place. Je préfère nettement cette méthode; on enlève complètement la couche PPP. Ne pas confondre RFC1483 bridging avec configurer le modem en bridge-mode qui peut se faire même avec PPPoE/PPPoA; configurer le modem en bridge veut souvent dire pas de NAT. Hello, Ce n'était pas un abus de langage, mes DSLAM ne sont que des gros commutateurs Ethernet qui ont d'un côté des ports xDSL et de l'autre un raccordement vers le MAN. C'est donc bel et bien du bridge D'ailleurs dans ta configuration tu as : interface ATM0/0/0.35 point-to-point […] atm route-bridged ip Ce qui signifie que tu ne fais pas directement de l'IP encapsulée dans de l'AAL5 mux, mais de l'IP over Ethernet over AAL5 snap. Ce qui permet par exemple de faire du DHCP en face pour ceux qui le veulent. Donc /in fine/ que ta trame Ethernet contiennent de l'IP ou du PPP, le DSLAM ne voit passer que de la communication MAC à MAC. Ce que fais ton FAI sur de l'ADSL, je le fais ici sur des SDSL où le layer IP est terminé sur un routeur d'agrégation derrière le DSLAM. -- Antoine Versini - Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] feature licenses sur Juniper MX midrange : ce qui change avec JunOS 13
Le 24 mars 2014 à 21:54, Jérôme Nicolle jer...@ceriz.fr a écrit : Comme je viens de passer une semaine à rassembler les pièces du puzzle, voici un récap à destination de ceux qui ont fait le choix d'utiliser une release toute neuve (ou un modèle pas supporté par des releases éprouvées). As-tu perdu la tête, Jérôme ? Poster dans une liste de diffusion de juristes des informations techniques, et qui plus est pouvant se révéler utiles à des ingénieurs œuvrant chez des hébergeurs ou des opérateurs… Reprenons nos esprits, veux-tu ? -- Antoine Versini --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [TECH] [FRnOG] [MISC] feature licenses sur Juniper MX midrange : ce qui change avec JunOS 13
Le 25 mars 2014 à 12:52, Clement Cavadore clem...@cavadore.net a écrit : Avec aversini, c'est vendredi tous les jours ! Oh Clément, tu t'es aussi inscrit à la FAC de droit par erreur ? -- Antoine Versini --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Recherche de contact Numéricable
Le 14 mars 2014 à 10:25, Yoann Gini yoann.g...@gmail.com a écrit : Au temps pour moi, j’ai cru que le but de FRnOG était d'améliorer la qualité d'Internet et autres services IP en France. Et nous allons d'ailleurs créer dans cette optique une nouvelle division qui devrait permettre d'apporter des raccordements FTTH à 10Gbit/s symétriques avec /19 IPv4 inclus pour ce que d'aucuns considèrent comme étant le bon tarif : payer l'abonné. Et le tout sans bousiller vos colonnades en faux marbre. Fidèle à la mission que vous venez de nous attribuer, nous allons également proposer un service 5G permettant (selon des sources journalistiques fort bien informées) de télécharger un film en une fraction de seconde. La technologie que nous mettons au point pour satisfaire cette quête insatiable de qualité (qui devrait prendre fin dès que vos accès personnels seront opérationnels, les autres pouvant -- en toute logique -- retourner crever la bouche ouverte) devrait d'ailleurs permettre l'envoi du contenu en question avant même que vous en ayez eu l'idée. Nous travaillons aussi en partenariat avec Pizza Hutt pour que le livreur sonne à votre porte 5 minutes avant le début de la projection. Il fera également attention à ne pas rayer le faux marbre avec son scooter. Le comité des nominations du FRNoG a longuement délibéré et a porté son choix sur Captain America pour prendre la direction de cette nouvelle structure. En espérant avoir pu vous conforter dans vos croyances, nous vous souhaitons une excellente fin de journée (avec, qui sait, peut-être un gain inespéré aux jeux - le tout étant d'y croire.) -- Antoine Versini --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [JOBS] Recrutement ingénieur réseau H/F en CDI (Paris)
Le 12 févr. 2014 à 08:08, m3g4g0lG0t|-| megagolg...@altern.org a écrit : Le 11/02/2014 22:24, Antoine Versini a écrit : La rémunération sera en fonction de l'expérience, plus avantages. Ca reste tout de même très (trop?) vague... 30k brut plus 60€/mois pour le café?? Certes. Nous recrutons aux prix normaux/légitimes du marché du travail pour ces niveaux de qualifications et d'expérience. Nous sommes donc bien loin de l'ordre de grandeur que vous citez. Concernant les avantages cités, on notera entre autres choses l'intéressement dont bénéficient nos collaborateurs (pouvant allez jusqu'à un 13ième mois) ainsi qu'une excellente mutuelle, connexion Internet à domicile, téléphonie, etc… -- Antoine Versini - Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [JOBS] Recrutement ingénieur réseau H/F en CDI (Paris)
NERIM SAS recrute un(e) ingénieur(e) réseau H/F en CDI. Descriptif du poste : - Les principales missions au sein de l'équipe réseaux télécoms seront de : • Participer activement à l'ingénierie et au déploiement de l'infrastructure réseau et télécom de Nerim. • Participer à la conception et à l'implémentation des offres de services proposées par Nerim à ses clients. • Prendre des initiatives pour l'évolution, l'expansion ou la réorganisation de cette-même infrastructure, en terme de technologies utilisées, de conception ou de services proposés. • Prévoir et assurer les augmentations de capacité, et de façon plus générale s'assurer de l'évolution des infrastructures en terme de dimensionnement par rapport à l'activité de la société. • Prendre à sa charge tout projet confié par le responsable réseau et télécom, et le mener à son terme avec autonomie. • Participer au maintient en condition opérationnelle de l'infrastructure réseau. • Assurer la prise en charge d'incidents majeurs signalés par le NOC requérant l'intervention d'un ingénieur qualifié. • Effectuer au responsable du département réseau et télécom une remontée d'information récurrente sur l'état des infrastructures, et alerter en cas de détection de dysfonctionnements. Le poste est sis au siège de la société (Paris, 8e arrondissement à deux pas de la gare St Lazare, boulevard Haussmann.) Il s'agit d'un contrat à durée indéterminée (CDI.) La rémunération sera en fonction de l'expérience, plus avantages. Profil recherché : -- Idéalement, nous recherchons une personne titulaire d'un BAC+5 diplômée en ingénierie réseau, avec 3 à 4 années d'expérience. Néanmoins un profil équivalent non-diplômé mais justifiant d'une expérience de plus de 5 ans validée chez un ou des opérateurs sera considéré avec autant de valeur, si ce n'est plus. Les compétences et connaissances requises sont les suivantes : • Parfaite maîtrise des cœurs de réseau MPLS, et notamment des technologies liées à MPLS telles que le traffic-engineering, les VPN MPLS (VRF, L2VPN, VPLS) et tous les protocoles impliqués (BGP avec extensions multi-protocoles, IGP à état de lien et à contraintes, signalisation de LSP, …) • Connaissance des technologies de concentration d'accès à débit crête (PPP, L2TP) ou à débit garanti (HQoS Ethernet, ATM) ainsi que des supports télécoms sous-jacents (FTTE, xDSL.) • Connaissance des architectures et des technologies orbitant autour d'Ethernet typiquement impliquées dans les services d'hébergement physique ou virtuel. • Connaissance des routeurs Cisco Systems et Juniper Networks. Enfin, des formations sur tous les autres équipementiers (notamment Huawei et Alcatel) ou technologies utilisées n'étant pas mentionnées ci-dessus seront dispensées afin de permettre à notre nouvel ingénieur d'appréhender l'ensemble de nos infrastructures tout-à-fait sereinement. La société : Nerim est un opérateur télécom, hébergeur et fournisseur de connexions à Internet fondé en 1999. Nerim est indépendant du point de vue des industriels du secteur et son actionnariat est en partie porté par ses salariés et ses dirigeants. L'infrastructure réseau est entièrement conçue, déployée et opérée au sein de la société. Il n'y a pas d'outsourcing de prestations afin de garantir la plus grande liberté d'innovation ainsi que la réactivité nécessaire dans ses opérations quotidiennes. Nerim fut ainsi le premier FAI à fournir IPv6 dual-stack sur ses connexions, le premier à fournir des connexions SDSL en G.SHDSL.bis ou était prête plus d'un an avant l'autorisation de l'ARCEP de la technologie VDSL2. Ceci notamment grâce à son propre réseau de dégroupage de la boucle locale. Enfin Nerim dispose d'un réseau national présent dans toutes les grandes agglomérations françaises ainsi qu'un réseau européen assurant une présence en propre à l'international (UK, NL, DE, CH, en continuelle expansion.) Enfin Nerim promeut et applique strictement tous les principes du peering ouvert ainsi que de la neutralité du Net. Notre siège bénéficie d'une connexion à 10Gbit/s vers notre backbone sans filtrage ni manipulation du trafic au même titre que l'ensemble des connexions et prestations délivrées. En adressage public, naturellement. Si vous êtes intéressé(e) par notre offre d'emploi et souhaitez des informations complémentaires ou vous porter candidat, veuillez répondre à ce message en privé. Salutations, -- Antoine Versini - Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] NERIM DOWN ?
Bonsoir, Nous avons en effet eu à déplorer un incident majeur sur notre backbone ce soir. Les Route-Reflectors du réseau ont cessé de remplir leur rôle pour une raison qui reste encore à déterminer. Cela a laissé l'ensemble des routeurs participant au BGP avec des tables de routage vides, incomplètes voire incohérentes. En première analyse il semble que les processus de routage de ces machines aient coupé l'ensemble de leurs sessions vers leurs clients peut-être suite à un comportement erratique d'un routeur situé à Amsterdam. Le journal de ce dernier montre que son processus de routage a planté -- purement et simplement. Un case a été ouvert chez le fabricant qui dispose des journaux et des accès nécessaires pour tâcher d'identifier la racine du mal. La leçon que nous tirons de cet événement assez incroyable est que la tâche de Route-Reflector, hautement critique, ne doit pas être confiée à des fabricants/architectures/implémentations identiques. Nous allons donc nous atteler à consolider notre gestion du routage en déployant d'autres réflecteurs sur des architectures et du logiciel autre que ce que nous avions jusqu'alors. -- Antoine Versini -- Nerim Le 12 nov. 2013 à 20:20, Xavier Lemaire xav...@zelites.org a écrit : Bonsoir, Le réseau Nerim est de nouveau UP mais que s'est il passé ? une petite explication serait la bienvenue. Bien cordialement 2013/11/12 Mariam El Bekkari mariam.elbekk...@tradingcentral.com Oui mais ce n'est pas encore stable. D’après le support technique l'opération est toujours encours. On 12 November 2013 19:35, Gaëtan Duchaussois gaetan.duchauss...@laposte.net wrote: Bonjour, chez nous c'est revenu. Coupure entre 18h47 et 19h29 environ Le 12/11/2013 19:18, Mariam El Bekkari a écrit : J'ai pu joindre le service après plusieurs tentatives. www.nerim.fr est inaccessible . On 12 November 2013 19:16, Mariam El Bekkari mariam.elbekk...@tradingcentral.com wrote: Oui ! ils ont une panne réseau ! 2013/11/12 Xavier Lemaire xav...@zelites.org Bonjour, On cherche à joindre un support chez eux leur téléphone est down comme leur réseau. depuis 29 minutes -- Xavier Lemaire Fax 33 244 84 05 15 TEL FR 33 2 22 06 41 02 GSM Morocco 212 6 58 30 01 81 xav...@zelites.org --- Liste de diffusion du FRnOG http://www.frnog.org/ -- *Mariam El Bekkari* System and Network Administrator MOBILE +33 6 10 05 74 23 Independent Research House Of The Year (Runner-Up) The Technical Analyst Awards 2013 ® See resulthttp://www. technicalanalyst.co.uk/conferences/Awards13.htm [image: Runner-Up] -- *TRADING Central SA* 11 bis rue Scribe F - 75009 Paris Tel. (+33) 1 5528 8040 Fax. (+33) 1 5528 8049 *TRADING Central Asia Ltd* 60 Wyndham Street, 2003B Central, Hong Kong Tel. +852 2522 3988 Fax. +852 3015 5851 *TRADING Central International Ltd* 36 Old Jewry London. EC2R 8DD Tel. +44 (0) 203 440 7615 Fax. (+33) 1 5528 8049 *TRADING Central Americas, Inc* 1150 6th Ave - 6th Floor New York, NY 10036 Tel. (1) 212 847 2387 Fax. (1) 646 861 4896 TRADING CENTRAL is available on BLOOMBERG, THOMSON REUTERS, TELEKURS, and SUNGARD MARKETBEAT - a joint product with DOW JONES NEWSWIRES - is available on BLOOMBERG and THOMSON REUTERS WEB: www.tradingcentral.com -- Copyright 1999 - 2013 TRADING CENTRAL The information contained in this publication is not intended as an offer or solicitation for the purchase or sale of any financial instrument. Any opinion offered herein reflects TRADING Central current judgment and may change without notice. Users acknowledge and agree to the fact that, by its very nature, any investment in shares, stock options and similar and assimilated products is characterised by a certain degree of uncertainty and that, consequently, any investment of this nature involves risks for which the user is solely responsible and liable. Services in the U.S. are offered through Trading Central Americas, Inc. This message is intended for recipient only and not for further distribution without the consent of TRADING Central. Although TRADING Central attempts to sweep e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. --- Liste de diffusion du FRnOG http://www.frnog.org/ -- *Mariam El Bekkari* System and Network Administrator MOBILE +33 6 10 05 74 23 Independent Research House Of The Year (Runner-Up) The Technical Analyst Awards 2013 ® See resulthttp://www.technicalanalyst.co.uk/conferences/Awards13.htm [image: Runner-Up] -- *TRADING Central SA* 11 bis rue Scribe F - 75009 Paris Tel. (+33) 1 5528 8040 Fax. (+33) 1 5528 8049 *TRADING Central Asia
Re: [FRnOG] [ALERT] Problèmes chez Nerim
Bonsoir, Je me permets d'intervenir sur la partie backbone, pour la partie SDSL je ne peux que vous recommander d'ouvrir un incident à notre support. Je n'ai pas eu de remontées de loss sur le réseau et l'ensemble de la matrice de trafic était normale. La plupart des routeurs du réseau limitent très fortement les réponses aux sollicitations extérieures à notre AS, avoir du loss en pinguant de façon cyclique un de nos routeurs est normal. Ce qui ne l'est pas c'est avoir du loss sur le ou les sauts finaux. Néanmoins comme le montre votre MTR, sur une session de plus de 17000 secondes (presque 5h) le traffic-engineering a re-routé plusieurs fois le LSP acheminant le trafic entre le point d'entrée ayant les peerings SFINX et le routeur d'accès auquel est raccordé le SDSL cible. C'est pour cela que vous voyez plusieurs noms de routeurs différents par hop tout au long du traceroute. Le réseau étant programmé pour ré-agencer le tissage de LSP du traffic-engineering toutes les demi-heures. Si à un moment la route s'étend de un ou plusieurs sauts, le dernier hop peut ne plus être l'IP cible du MTR. C'est typiquement ce que l'on observe ici : 13. jolivet-142-62.cnt.nerim.net nb sp; 20.4% 17627 18.7 59.6 5.0 2067. 148.0 fa0-0-nas202-dsl-stdenis.nerim.net xe0-0-2-138.edg-sde-4.nerim.net te2-3-177.bbn-vtr-1.nerim.net Ce saut a été alternativement plusieurs équipements différents, incluant deux routeurs backbone dont le loss normal a été agrégé avec le saut représentant votre IP cible. Je me suis permis de lancer un traceroute monitor depuis le routeur d'entrée sur le réseau (celui ayant les peerings SFINX) vers votre connexion SDSL et je n'ai pas noté de problèmes pour le moment. HostLoss% Snt Last Avg Best Wrst StDev 1. te4-1-78.bbn-vtr-1.nerim.net 0.0% 500 70.2 9.8 0.8 202.8 28.9 2. te2-1-94.bbn-sde-2.nerim.net 0.0% 5001.0 6.6 0.8 178.0 22.8 3. te2-4-80.bbn-sde-1.nerim.net 0.0% 5001.0 6.1 0.8 193.1 18.8 4. xe0-0-2-138.edg-sde-4.nerim.net 0.0% 5000.7 3.5 0.6 90.9 8.9 5. te2-3-138.agr-sde-4.nerim.net 0.0% 5000.7 2.7 0.7 42.2 6.6 6. fa0-0-nas202-dsl-stdenis.nerim.n 0.0% 5001.0 2.7 0.8 84.4 6.7 7. jolivet-195-26.cnt.nerim.net 0.0% 500 13.3 15.9 12.2 139.1 9.6 Salutations. -- Antoine Versini - Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Frnog et profs/chercheurs/écoles [Was: Le routage, enjeu de cyberstratégie]
Auriez vous la bonté de rétablir la vérité avec les détails, genre date, personne, lieux etc …. Des Cisco 4000 sous IOS 11, routant des /48 dans 3ffe::/16 via des tunnels. Les lieux, comme toujours dans la France jacobine, c'était en région parisienne, dans des POP opérateurs (il n'y avait gère que Telehouse 1 comme DC neutre de toute façon.) Quant aux personnes, peu importe. Quelques illuminés qui se sont trouvés un nouveau trip tout au plus. Bref, le but n'est certainement de lancer un troll dans le troll. Rappelons notamment à toutes les personnes qui ont eu le mauvais goût de basher la recherche que nous devons les principes de communication par paquets désordonnés, de réseau par couches (3 à l'époque) agnostique aux applicatifs et, plus généralement, d'inter-nets, à Cyclades. Réseau français développé au début des années 70 par l'INRA (ancêtre de l'INRIA) auquel lui fut, malheureusement, préféré Transpac. Nos amis outre-atlantique s'en sont d'ailleurs largement inspiré pour la création d'ARPANET. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Frnog et profs/chercheurs/écoles [Was: Le routage, enjeu de cyberstratégie]
Je suis trop jeune pour témoigner mais il ne me semble pas que le réseau 6bone ait jamais eu pour objectif de faire un réseau de production. Remettons chacun dans son rôle, ce n'est pas aux chercheurs de fournir (ni même d'appliquer) les best practices. D'ailleurs beaucoup de chercheurs en réseau ne dépassent pas le stade de la simulation, question de praticité. Et quand expérimentation il y a, elle se fait sur des petites machines sous Linux ou BSD et non sur des gros Cisco capables de router 10Gbps sur leur chip FPGA. Les deux sont complémentaires, et je ne pense pas que les initiatives de RENATER, l'INRIA, l'Institut Telecom et consors soient à minorer par rapport à celle de NERIM. Je poste depuis mon adresse Nerim, mais à l'époque nous n'existions pas. Ce n'était donc pas le but de mon intervention (sinon j'aurais évoqué l'apparition des premiers accès broadband en dual-stack il y a 10 ans, mais Ipv6 était déjà déployé par ailleurs.) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Frnog et profs/chercheurs/écoles [Was: Le routage, enjeu de cyberstratégie]
Bonjour, Les premier à avoir déployé de l'IPv6, du multicast, etc…. avec RENATER ça a été nous. Sachez que ceci est faux. Navré pour nos amis du réseau académique. Cela avait d'ailleurs été rappelé au ministre de l'industrie blabla-titre-pompeux de la précédente mandature lors d'un sommet dédié à IPv6. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Frnog et profs/chercheurs/écoles [Was: Le routage, enjeu de cyberstratégie]
Le 9 janv. 2013 à 11:51, Samuel Thibault samuel.thiba...@ens-lyon.org a écrit : Et combien d'enseignants/chercheurs qui ont passé leur chemin, parce qu'ils ont compris de la page qu'ils n'étaient pas bienvenus ? Si c'est réellement le cas, alors un tel niveau de stupidité doit les handicaper dans leur existence quotidienne. Leur principal problème n'est donc plus de pouvoir s'inscrire ou pas à une réunion FRNOG. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [JOBS] Nerim recherche un ingénieur réseau et télécom
Bonjour, Nerim est actuellement à la recherche d'un ingénieur réseau et télécom confirmé avec 4 à 5 années d'expérience dans le milieu des opérateurs de réseaux / ISP / NSP. Le poste est à pourvoir dès à présent. Type de contrat: CDI Rémunération: selon expérience Lieu de travail: Paris Pour plus d'informations sur le profil recherché et les missions associées à ce poste : http://www.nerim.fr/recrutement Salutations. -- Antoine Versini Responsable réseau et télécom - Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Collecte Régionale LR
On 11/03/11 11:46, Ducassou Laurent wrote: A ma vu, cette partie va être sympathique car elle permet la collecte de site en SDSL ou en Fibre Optique mais pas de ligne de type ADSL par contre. Ce n'est pas plutôt CE2O que Core Ethernet pour la collecte optique ? En tout cas les feuilles CE2O sont livrables sur des troncs DSL-E ATM mutualisés ou sur des portes Ethernet dédiées, indifféremment. -- Antoine Versini - Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Collecte Régionale LR
On 11/03/11 12:15, Jérôme Hiezely wrote: Non il existe bien une nouvelle offre depuis ce début d'année qui est Core Ethernet Lan (article 8 de l'OFR Orange) L'offre Core Ethernet n'a-t-elle pas plus pour vocation de créer des réseaux multipoints type VPN layer 2 pour entreprises que de faire de la collecte de circuits par des ORT comme en CE2O ? -- Antoine Versini - Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: Collecte Régionale LR
On 10/31/11 18:58, Jérôme Nicolle wrote: [...] tu ne peux pas oversubscriber la porte. Techniquement, la somme des PCR peut (largement) dépasser la capacité du support physique, mais pas celle des SCR en revanche. Tu as également une limite du nombre de circuits. -- Antoine Versini - Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: Le troll du vendredi par Michel
On 10/27/11 10:07, Guillaume Leclanche wrote: Apres pour plagier un expert sur le sujet, il arrive que ipv6 sur le LNS ca marche juste pas... ouais, bon il arrive avec le matos des tas de trucs pas liés à IPv6 qui nous laissent sur le cul chaque jour. Et plein d'opérateurs y compris sur cette liste ont fait marcher IPv6 sur leur LNS. Dans le cas d'un fabriquant dominant de matériel réseau, l'implémentation IPV6CP a été faite de longue date et ne pose pas de problème au quotidien. (Dans certaines circonstances il est nécessaires d'utiliser des attributs vendor-specific dans les profils RADIUS, c'est tout.) Je suis assez curieux de savoir de quelle(s) plate-forme(s) l'expert en question parlait. -- Antoine Versini - Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Datacenter à courbevoie
On 10/23/11 18:59, Jérôme Nicolle wrote: ldn-5-6k#ping 213.251.130.4 Fake. C'est bien connu que l'ICMP ça sert à rien et c'est pas fiable. C'est d'ailleurs pour ça qu'on le filtre, hein ? Disons surtout que se fendre d'une grosse explication sur les latences des systèmes de câbles sous-marins en initiant des ICMP Echo depuis un IOS et vers un autre IOS, c'est pour le moins assez funky. Le process ICMP de l'IOS fait partie de ceux qui ont le moins de priorité. Pour s'en convaincre, il suffit de lancer un ping pendant qu'un des deux comparses exécute BGP Scanner et ainsi voir la latence tendre vers l'infini (et ce, même sur une plate-forme qui sépare data et control plane.) --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: Datacenter à courbevoie
On 10/24/11 13:11, Sam Preston wrote: Donc avec un RTT ICMP de 8 ms (dans l'exemple d'Octave), ça démontre bien que le RTT entre Paris et Londres (au moment de la mesure) est inférieur à 8 ms. Et par conséquent, l'explication n'a rien de funky, bien au contraire ! Je vais argumenter un peu, dans ce cas :-) Sans se lancer dans une thèse d'épistémologie ou l'analyse de la Critique de la Raison pure, on sait globalement que toute sciense dérive peu ou prou de l'observation. Une démarche scientifique de base consiste à s'assurer en premier lieu que ses outils d'observation et de mesure n'induisent pas de biais. L'ingénierie, en étant une application concrète des sciences, ne s'y soustrait pas. Donc je suis navré, mais je vais maintenir que faire une démonstration sur la base d'un outil au comportement imprévisible n'est pas de nature à valider ces quelques assertions dictées sur le ton du professorat (et je passerai sur la remarque RTT vs temps de transit cherchant à maladroitement noyer le poisson.) Bien que techniquement les valeurs relevées restent du domaine du concret. Quant à ce qu'elles démontrent réellement, c'est une autre histoire. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: LISP : besoin d'avis
On 10/14/11 16:42, Guillaume Barrot wrote: Perso j'avais commencé à bosser sur un proto à base de DHCP sur les interfaces physiques, d'un démon de routage et le service porté sur une loopback, mais l'idée d'avoir une table de routage peuplée de /32 dans tous les coins ... du bricolage je vous dit ! Ici aussi nous avons un besoin identique avec les datacenters virtuels reposant sur plusieurs infrastructures physiques connectées entre elles par un réseau routé : les VM peuvent tourner à un instant t sur un hôte dont on ne connait pas la localisation (on s'approchaine du principe d'incertitude en informatique, cela n'augure rien de bon ;-) .) Puisque vous citez Vmotion, je pense que le fournisseur d'hyperviseur concerné pourrait par exemple implémenter OSPF dans Vshield pour faire annoncer les adresses IP de chacune des VM qu'un hôte physique héberge à cet instant. J'admets que cela revient à remplir une RIB de /32, mais ce peut être résolu assez simplement avec une aire NSSA /ad hoc/ par exemple pour ne pas perturber le coeur. Je ne pense donc pas qu'il soit nécessaire d'inventer ou implémenter de nouveaux protocoles pour répondre à une problématique somme-toute assez basique que d'autres protocoles plus anciens peuvent déjà résoudre. Il suffirait que les fournisseurs de systèmes de virtualisation poussent un peu plus loin sur les questions de réseau (questions qu'ils créent eux-même en partie, par ailleurs.) Malheureusement, c'est souvent le réseau qui doit se plier aux exigeances du système / de l'applicatif, mais rarement l'inverse. Le plus gros écueil observé reste que souvent la limite entre les deux mondes n'est pas connue ou définie par les concepteurs de logiciels, conduisant ainsi à de belles technologies de virtualisation ou autre qui vont devoir reposer sur des infra réseaux miteuses. La LoL-génération traduirait ceci par : Fail. -- Antoine Versini - Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [FRnOG] RespectMyNet : Une plate-forme citoyenne recense les restrictions d'accès au Net
On 09/26/11 12:51, Clément Guivy wrote: j'ai aussi eu un cas de rate-limiting évident chez Nerim (en ADSL) vers certaines destinations (tout ce qui sortait du réseau Nerim en fait), ce n'était peut-être seulement qu'un problème technique mais je n'aurai jamais le fin mot de l'histoire, ayant préféré résilier suite à des semaines de bataille infructueuse avec le service technique. Des exemples de réseaux vers lesquels le trafic ne passait pas à un débit satisfaisant ? La seule discrimination faite par l'ensemble du réseau consiste à classifier le trafic voix sur IP pour le faire passer dans des strict-priority queues. C'est tout. Il n'y a et n'aura jamais rien d'autre. -- Antoine Versini - Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [FRnOG] Re: [FRnOG] RespectMyNet : Une plate-forme citoyenne recense les restrictions d'accès au Net
On 09/27/11 14:09, Frédéric wrote: La seule discrimination faite par l'ensemble du réseau consiste à classifier le trafic voix sur IP pour le faire passer dans des strict-priority queues. C'est tout. Il n'y a et n'aura jamais rien d'autre. c'est déjà trop. Allons bon... Je suis plus qu'impatient de connaître l'argumentation politico-économico-géostratégique se cachant derrière l'assertion qu'un trafic temps-réel, cloisoné au réseau qui plus est, ne devrait pas pouvoir emprunter le cheminement précisément adapté au temps-réel proposé par les équipements. D'autant plus si ce traitement ne perturbe en rien le trafic non-classifié. On cherche juste à garantir le temps de transit au sein des équipements, par à empêcher quiconque d'aller sur le site de son parti politique préféré. Nonobstant le fait que dans un réseau surdimensionné où par état de fait rien ne sature et dans lequel rien n'est limité, le traitement de l'ensemble du trafic est fondamentalement agnostique eût égard aux couches applicatives. Que je sache, le champs ToS de l'en-tête IP existe depuis bien avant que cette bouillie politico-idéologique qu'est la Net Neutralité ne se généralise, et son but n'a jamais été de n'être qu'esthétique. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [FRnOG] RespectMyNet : Une plate-forme citoyenne recense les restrictions d'accès au Net
On 09/27/11 16:17, Stephane Bortzmeyer wrote: Je n'ai pas vérifié les pratiques de Nerim sur son réseau, mais ce genre de langage en dit long sur la mentalité de certains opérateurs, et montre bien que les utilisateurs ont parfaitement raison d'être paranoïaques, et de se méfier de leur FAI. Ce language ne dira que ce que vous voulez vien vouloir lui faire dire pour faire valoir votre point de vue. En vous gardant bien, naturellement, d'en faire la correcte interprétation (il est vrai, à votre décharge, que cela ne réside pas dans la manpage de dig(1)...) Le propos, donc, n'a rien à voir avec la légitimité ou non de la neutralité. Je me garde bien d'exprimer ma position par ailleurs, mais prends un malin plaisi à stygmatiser le mélange des genres infect que ses défenseurs les plus fervents nous imposent. Apprenez donc à mieux identifier vos cibles, par-ce que commencer à tirer sur celles qui -- pour le coup -- partagent potentiellement la même opinion en dit au moins aussi long sur l'hystérie généralisée reignant autour de ce sujet. Pour finir, les opérateurs dominants pourront bien aller quémander ce qu'ils veulent chez les technocrates de Bruxelles, cela n'empêchera pas qui le souhaite de continuer à bâtir un réseau d'accès et de coeur neutre et l'interconnecter à des points d'échange et des transitaires opérant de la même manière. Ainsi les utilisateurs paranoïaques en question de choisir leur fournisseur de connectivité en fonction. Mais ils feraient bien mieux de placer leur défiance et leur paranoïa ailleurs par les temps qui courrent... --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] RespectMyNet : Une plate-forme citoyenne recense les restrictions d'accès au Net
On 09/27/11 17:07, Jérôme Nicolle wrote: Non, la problématique n'est pas transposable. Dans le cas d'un ISP dual ou triple play, le service Internet et le service Voix sont deux flux distincts, qu'ils passent ou non techniquement par le même câble/vc/vlan/whatever. C'est d'ailleurs _précisément_ la demande des clients, à ce que le service de téléphonie (peut importe comment il fonctionne dans les faits) ne soit pas perturbé par le service de connectivité à Internet. Nous ne serions pas neutre vis-à-vis du traitement spécifique de la téléphonie si l'on dégradait SIP(S), H.323, MGCP et RTP/RTCP vers des adresses qui ne sont pas identifiées comment faisant partie de la plate-forme de service. Mais ça, Internet et sa grande roulette russe des paquets risque de le faire de facto puisque souvent il suffit d'un petit passage via certains réseaux pour que la notion de best effort sur le réseau public prenne tout son sens. Et des gens de croire subséquemment qu'on dégrade leur trafic volontairement... --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Flap plateforme SFINX sur TH2
On 08/04/11 10:18, Simon Muyal wrote: Je partage l'avis de Raphael que la liste FRnOG n'est pas faite pour traiter les incidents d'un IXP. D'autres canaux existants sont plus appropriés (par exemple pour le SFINX, noc-sf...@noc.sfinx.fr en premier et mailing list SFINX pour faire du reporting/corrélation éventuellement). A contrario, puisque la ML SFINX n'est pas un endroit indiqué pour discutter des problématiques de fond, mais plutôt des questions opérationnelles, ne serions-nous donc pas en droit de poser ouvertement la question du choix de ces nouveaux équipements sur FRNOG ? Avant ça fonctionnait correctement, à présent c'est nettement moins bien... Ce n'est pas comme si de sérieuses réserves n'avaient pas été émises en réunion SFINX quant à ces prétendues évolutions. -- Antoine Versini - Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: Plus d'IPv4 en Asie, on est les prochains!
On 04/15/11 12:01, François Tigeot wrote: Pour Nerim, même si ils peuvent fournir une connectivité IPv6, il faut le demander / l'activer spécialement. Le routeur par défaut proposé pour les ligne SDSL ne gère que de l'IPv4 par exemple ... C'est en effet le cas des anciens CPE Motorola que nous fournissions dans le cadre des offres xDSL, mais nous les avons remplacés par des CPE Cisco qui gèrent IPv6. Quoiqu'il en soit, depuis 2003, chaque client a un /48 réservé par le SI lors de la création de son/ses services(s). -- Antoine Versini - Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Troll du mardi
On 01/25/11 14:27, Damien Wetzel wrote: est ce la fin de l'AS 41690 ? y'a t'il du démanagement de plateforme à prévoir vers l'AS 3215 ? Il semble évident qu'en terme de consolidation des coûts, ça va se retrouver dans la galaxie FT. Et que se soit 3215 ou 5511, cela importe finalement peu. Mais là où toute cette histoire devient particulièrement croustillante, c'est qu'à terme en positionnant cette plate-forme de streaming derrière un AS faisant saturer sciemment sa connectivité entre l'Internet-par-Orange et l'Internet-tout-court, les FAI tels que nous qui utilisons encore pas mal de collecte en option 5 vont voir la consommation baisser mécaniquement sur cette dernière. Et les coûts de collecte n'ont rien, mais alors vraiment *rien* à voir avec les coûts de transit. Une gausserie de circonstance s'impose (la génération IPv6 dirait LoL.) -- Antoine Versini - NERIM --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] GBLX / ORANGE
On 01/17/11 20:04, Vincent Gillet wrote: Les autres opérateurs de transit plus low-cost (la liste est facile a faire !) se voient baladés pour les upgrades de peering car il n'y a pas d'intéret mutuel. C'est la base du peering. Salut, Je suis navré, Vincent, mais je suis absolument pas d'accord avec ton point de vue et ce pour les multiples raisons suivantes. D'une part, peu importe le coût auquel un acteur international commercialise son transit, le peering avec lui (en tant que partenaire tier-1) a un intérêt mutuel inhérent -- en dehors du fait de consolider son propre status de tier-1 -- car ce dernier doit être en mesure d'acheminer le trafic d'un de ses clients lointains vers ton réseau, au même titre que tu va réaliser l'opération inverse. Ensuite, en tant qu'acheteur de transit chez des opérateurs que tu n'as pas cité dans ta liste -- j'en conclus donc qu'il font parti des honnis -- je constate que la connectivité proposée, dans sa globalité, est très satisfaisante et en aucun cas différente à l'international par rapport à ce que j'ai pu avoir par le passé chez DTAG, Sprint ou Level3. Je me fonde sur des Smokepings, pas sur un ressenti subjectif. Et aussi que les clients ne se plaignent régulièrement que de la connectivité hasardeuse vers la galaxie FT. En gros, ça couine juste avec OT. Il semble donc manifeste que le seul intérêt que tend à sauvegarder la politique de peering d'OT est de limiter la pénétration d'acteurs majeurs ayant la taille critique leur permettant de commercialiser à des prix sur lesquels OT ne peut pas facilement s'aligner sur son propre terrain. Soyons honnêtes : les techs de transmission LD ou la maturité des routeurs IP high-end est telle qu'à présent déployer et maintenir un réseau international de bonne qualité n'est devenu qu'une question de volonté et de moyens, et largement moins de savoir-faire et de compétence. Il y a encore quelques brebis galeuses que nous connaissons tous, mais c'est très probablement parce que ces réseaux n'y mettent ni l'un ni l'autre ou un mix improbable des deux. N'en parlons donc pas. Dans ce cas, qui est OT pour estimer qu'un réseau X ou Y n'a pas le droit à une connectivité décente avec lui, à partir du moment où il satisfait aux mêmes critères de présence internationale, de ratios, de volume, de ne pas pratiquer de routage hot-potatoes, et d'avoir un NOC ? Réseaux qui doivent par ailleurs très probablement pour la plupart utiliser les mêmes technos/constructeurs qu'OT lui-même. Et enfin, pour les adeptes de la real-politik à la Kissinger, on pourrait aussi argumenter que la France, quand on s'appelle Monsieur Ztazunis ou Bollywood, c'est un peu un pays de nains râleurs sans grand intérêt au final et qui ne nécessite probablement pas non plus une débauche d'efforts particulièrs sachant que des réseaux d'incumbents ailleurs en Europe ne posent pas ces difficultés. De là à ce que les big badasses en aient leur claque à un moment et que le status de leurs intercos avec OT soit revus en paid-peering ou en transit -- remettant en cause conséquemment le status d'OT -- il n'y a qu'un pas. See you :) -- Antoine Versini - NERIM --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] GBLX / ORANGE
On 01/14/11 02:37, Damien Robinet wrote: Bonjour à tous, Je lis cette liste depuis plusieurs mois, mais je n'ai jamais participé :) Faut un début à tout :) Je me permets de solliciter votre avis sur GBLX en tant qu'opérateur de transite. En fait, nous avons dans nos opérateur GLBX justement, et depuis octobre, les débits entre GBLX et Orange sont purement catastrophiques. Lorsque l'on quitte le réseau Orange, on passe par l'Allemagne pour rejoindre GBLX et la le PING de 40ms se retrouve à partir sur du 280ms et se situe bien plus souvent dans le 300ms. Salut, C'est connu, en effet. Ils sont censés ajouter 2 nouveaux 10GE vers 5511 assez prochainement, un à Londres et un autre à Paris. À leur décharge, GBLX n'est pas la première victime de saturations vers OpenTransit, et malheureusement probablement pas la dernière. Quand la saturation-du-moment est avec le tier-1 X, il faut jouer des communautés BGP pour faire passer votre trafic via le tier-1 Y. C'est le jeu avec OpenTransit. C'est ça ou céder au chantage. Et prendre du transit 5511 pour se retrouver avec un problème bien pire (saturer avec tout le reste du monde pour pouvoir joindre à peu près décemment les réseaux d'Orange -et encore-), non merci ;-) -- Antoine Versini - NERIM --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Firewall HTTP
On 11/25/10 20:01, Rémy Sanchez wrote: Donc le DiffServ co c'est une vaste fumisterie ? On s'est amusé à utiliser de précieux octets dans les entêtes IP pour rien ? Personne ne fait de QoS ? Cela m'étonnerait fortement. L'utilisation du champs TOS des en-têtes IP pour effectuer un marquage DSCP des paquets issus de plate-formes de téléphonie/voix sur IP et de diffusion vidéo est un must dans tous les réseaux IP d'opérateurs. Les routeurs et commutateurs utilisent cette information pour assigner les paquets dans des files d'attentes prioritaire par rapport au traffic best effort (Youtube/Youporn/Faceplook.) -- Antoine Versini - Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] mode de connexion multiplay
On 10/28/10 11:50, Jacques VUVANT Gmail wrote: bonjour je dois faire une synthèse sur les modes d'authentification couramment utilisés par nos chers FAI et opérateurs(pppoe, dhcp ou bridge) sur les différents services (voip, vod, iptv et hsi). quelqu'un aurait-il un avis sur la question ? quel va être la tendance à moyen terme? qu'en est-il de l'IPV6 ? avez-vous des exemples (free, etc...) ? Bonjour, En plus de l'ADSL du pauvre, il existe également des prestations type SDSL qui peuvent être considérées comme la descendance moderne des ancestrales liaisons spécialisées type E1, et sur lesquelles il n'y a pas d'authentification (et inepte d'en faire, puisque dédiés.) Ce sont des conduits point-à-point, souvent brassés en ATM ou commutés en Ethernet entre les extrémités IP opérateur et utilisateur, où l'adressage IP est fixé définitivement sur les équipements et qui ne nécessitent par conséquent pas de DHCP ou autre 802.1x. Pour le reste de la masse, en ADSL, ça ne déviera jamais beaucoup du PPPoX avec RADIUS ou du MER avec DHCP. En ce qui concerne l'IPv6, il y a deux écoles. Ceux qui doivent déployer des artefacts en encapsulation pour bypasser du hard non IPv6 entre le CPE/IAD chez le end-user et le backbone, et ceux qui sont en dual-stack de bout-en-bout. Le dualstack sur du SDSL en EoATM est totalement straightforward, puisque c'est de l'Ethernet. En PPPoX c'est juste la couche IPV6CP qui est négociée en plus de la couche IPCP classique (avec avec un RADIUS + attributs FRAMED-IPV6-PREFIX ou éventuellement des vendors-specifics.) Q+ -- Antoine Versini - Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] mode de connexion multiplay
On 10/28/10 17:31, Refuznikster wrote: On utilise encore une authentification chez le particulier en france pour l'adsl ? Oui, tout ce qui est produit sur des collectes type option 5 nécessite une authentification, ne serait-ce que pour les BAS des opérateurs de boucle locale qui doivent déterminer vers quel FAI faire suivre la requête car il leur faut obtenir le point de terminaison de la session. -- Antoine Versini - Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: OVH crée un datacenter
On 10/07/10 14:47, Octave wrote: parce que c'est vrai ... comment dire ? ... le cube crée une emotion ... sans rire ... perso les kilometres de baies et de serveurs j'en voie tous les jours ... à force bof ... et là ... wouaouuu ... c'est ... impressionant ... très fort ... je crois que c'est la hauteur qui fait cet effet là ... en tout cas tu ressens quelque chose ... Je ne suis pas certain que ce type de construction soit à même de créer la même émotion que la grande salle hypostyle du temple de Karnak, à moins que l'on cherche à estimer la quantité de SPAM et de P2P qui y transite. Ou alors les gens succombant à ce charme épuré sont aussi ceux qui tombent amoureux d'une caisse de CRS-1 par-ce qu'ils n'ont jamais vu une commode Louis XVI de leur existence. Chacun ses standards, en fait... -- Antoine Versini - Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: Comment pénétrer('facile ment) le backbone d'un grand FAI
On 09/27/10 11:40, Clément Game wrote: Pour sûr et on a de nombreux exemples qui prouvent que cela ne fonctionne pas ... sendmail, linux, le dns, wordpress, apache ... et j'en passe et des meilleurs ;-) Ouais mais au moins on attend pas 3mois voir plus (voir pas de correction du tout) pour avoir les patchsCQFD Cela dit, on attend pas non plus très longtemps pour les nouveaux bugs/holes, donc l'un dans l'autre on s'y retrouve :') --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Réduction de la fracture n umérique
On 09/20/10 13:12, Pierre Lagoutte wrote: Puisqu'on est dans les chiffres: le ratio d'assymétrie UL/DL de Nerim pour la collecte IP/ADSL (qui adresse le plus gand nombre d'entreprises), et qui reflète bien les entreprises moyennes est de 20% (en débit crête), et est stable sur l'année. http://stats.nerim.net/nav/cipa/ Cet opérateur dédie l'essentiel de son business aux entreprises, et son réseau est largement dimensionné pour accueillir le trafic dans les deux sens sans générer trop de goulots d'étranglement. Bonjour, Attention, il y a dans ces volumes probablement plus de trafic de type non-pro que vous ne le supposez, car nous comptons encore un bon nombre (surtout en ADSL, ce qui semble logique) de clients particuliers qui n'en ont rien à fiche des sirènes du triple-play et qui préfèrent payer un poil plus cher pour une connectivité neutre à Internet. Salutations, -- Antoine Versini - Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Neutralité du Net
On 08/18/10 18:07, Dominique Rousseau wrote: D'ailleurs, je trouve qu'il est de plus en plus abusif de parler de FAI, quand on parle des opérateurs (triple|quadruple)-play. Ils fournissent un accès multi-services, dont, accessoirement (notamment en terme de CA, je pense) l'accès à Internet. Précisément ! À ce stade, ce ne sont plus que des réseaux de transport et de diffusion, pour le compte de sociétés qui produisent et/ou distribuent des contenus qui ne sont pas ceux du-dit FAI. Au même titre que TDF diffuse les grandes chaînes de télévision nationales (entre autre.) Et jusqu'ici, sauf erreur, il ne me semble pas que quiconque ait demandé à TDF de rendre son réseau hertzien neutre par exemple. Si demain, un des réseaux des FAI optait pour la possibilité de ne plus acheminer le contenu audiovisuel en IP multicast, et confiait cette tâche à une compagnie spin-off qui ne serait pas opérateur télécom ni FAI, en lui louant par exemple des waves sur le DWDM sous-jacent du réseau IP de la maison mère, alors il s'exclurait par un petit tour de passe-passe à cette obligation de neutralité. Car si on l'y obligeait malgré cela, ceci signifierait que n'importe quel opérateur IP (par exemple un tier-1 ne fournissant que du transit) devrait également se soumettre à cette obligation. Maintenant sur un plan plus technique, il va faloir expliquer comment des flux multicast vont pouvoir être acheminés en inter-domaine (est-ce le grand retour de MSDP pour les annonces de Rendezvous-Points de groupes ? Ha dommage, c'est un protocole propriétaire) avec une gestion des classes de service et des règles de QoS associées unifiée entre tous les réseaux de diffusion. Les collisions entre règles d'attribution d'IP de groupes multicast vont être très distrayantes également. Sans compter qu'un simple abonné envoyant un simple IGMP pourra (et devra, c'est bien là l'aspect le plus croustillant de la chose) recevoir le groupe de son choix, puisque le réseau de transport ne filtrera ou ne proxiera rien afin d'être neutre. Je pense que certain diffuseurs n'aprécierait pas de voir leurs flux répliqués, décodés et réinjectés en clair par ailleurs. -- Antoine Versini - Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Antispam : vaderetro, ironport, proofpoint... vos avis.
On 07/29/10 20:09, Radu-Adrian Feurdean wrote: [...] Ou il y a quelques mois l'afaire Nerim + UCEProtect (la j'ai bien rigole). Étrangement, nous, on a beaucoup moins rigolé que vous... Qu'est-ce qui a bien pu provoquer votre hilarité ? Qu'un opérateur résolument engagé dans la lutte contre le spam se fasse blacklister tout son AS par un système totalement inepte dont les créateurs eux-mêmes déconseillent l'usage ? Ce filtrage a empêché bon nombre de nos clients disposant de leurs propres MTA sans histoires, sans réseaux infectés, de continuer à envoyer leurs mails en toute sérénité comme ils l'ont toujours fait. Nous en sommes à présent au point de surveiller l'ensemble de nos clients afin de les prévenir (et de nous prévenir) --voire même de les bloquer-- s'ils sont infectés ou indélicats. Que voulez-vous donc que nous fassions de plus ? Vous en connaissez beaucoup des opérateurs qui ont le cran de bloquer leurs clients en cas d'abus manifeste de spam ? Je parle de clients corporate, pas de pékins derrière une stupidbox quelconque, hein. Ce n'est même pas notre métier, à la base. Nous sommes opérateur IP, pas je ne sais quoi qui nous forcerait à surveiller l'activité de nos clients. Et maintenant, c'est quoi la prochaine étape ? Il va peut-être faloir arrêter dans l'escalade de la violence en inventant toute sortes de techniques stupides, totalement disproportionnées et surtout qui créent plus de problèmes qu'elles n'en résolvent. -- Antoine Versini - Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Free aux abonnés absent ?
On 07/06/10 11:47, Jérôme Nicolle wrote: Tant que ça passe pas par une fusion avec l'asso France-IX ;) Je ne peux pas l'homologuer celle-ci, Jérôme. Néanmoins je salue la tentative en esthète. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Fwd: [PaNAP-Members] PaNAP / France-IX merging announcement
On Fri, 25 Jun 2010 23:21:43 +0200, Spyou r...@spyou.org wrote: Je rejoins juste l'opinion de vox à propos de la diversité Merci d'avoir su faire la part des choses Spyou. Nous appelons de nos voeux que la diversité des points d'échange soit maintenue. En ce qui nous concerne le débat ne porte en aucune manière sur le payant face à la gratuité. C'est un fait qu'en incluant tous les frais associés au réseau européen, nous payons largement plus cher le Mbit/s du LINX ou de l'AMS-IX que le Mbit/s de transit et que cette situation nous convient parfaitement. Monter des peerings afin d'optimiser les routes et ne pas dépendre uniquement de réseaux tiers, c'est non seulement la base d'Internet mais aussi quelque chose que nous pratiquons depuis largement bien plus d'une décennie -- époque où les évangélistes d'aujourd'hui n'avaient par ailleurs strictement aucune idée de ce que cela pouvait bien signifier. C'était même plus une question de survie qu'autre chose. Mais merci de prendre la peine de nous le remémorer au cas où nous l'aurions oublié. Ce n'est pas le cas, mais l'intention reste louable. Je l'ai dit et je maintiens : le point d'échange pour opérateurs après la (longue) parenthèse PARIX est, et a toujours été, le SFINX (à l'époque sus-mentionnée, cela s'apellait le GIX.) Créer un nouvel IX pour reproduire le modèle néerlandais ou anglais alors qu'en fait il existait déjà (mais étoffé par d'autres initiatives, dont la nôtre à l'époque chez TOF qui fut de créer le PaNAP; navré mais 'so far' pour la partie nous on a des initiatives, pas vous) puis ensuite, en essayant de raccorder les deux entre eux mais sans que se soit les mêmes -- mais un peu quand même (mais pas trop non plus, hein) -- alors là, en effet, on peut dire que c'est une brillante manifestation du caractère typiquement français (adepte de la confusion à tous les étages s'il en est.) Navré, mais point de visibilité accrue à l'aune de ce nouveau sac de noeuds. En France, on pense que réinventer le bidon de deux litres tous les ans va permettre d'empêcher les réseaux de distribution d'eau de fuir. -- Antoine Versini - Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Fwd: [PaNAP-Members] PaNAP / France-IX merging announcement
On 06/24/10 22:50, Raphael Maunier wrote: Dans l'annonce a AUCUN moment il y a eu un sous-entendu sur la préparation de chéquiers. Je suis navré, Raphaël, mais rien ne sous-entend le contraire non-plus. Cf. The modalities and timing of this operation are still being defined. À l'heure actuelle, Nerim est extrêmement satisfait des prestations du PaNAP qui est de notre point de vue un exellent IX et nous n'envisageons plus à l'heure actuelle d'autres raccordements (notamment suite à la réunion que nous avions eu avec vous.) Le moins que l'on puisse dire c'est que toute cette pagaille induite dans la topologie IX en France ne correspond pas à la vision que des opérateurs comme nous avons d'une production stable et diversifiée. Le SFINX se rapproche de France-IX, le PaNAP également. Nous considérons que c'est une perte de diversité. De par ces rapprochements pour le moins incongrüs, nous perdons non-seulement la garantie que les fabriques ne sont pas susceptibles de subir d'effet domino, mais en plus la possibilité pour nous d'établir des raccordements sur des POP différenciés qui n'ont pas de relations Layer 2 entre eux. Il est bien regrettable d'assister à une confrontation entre deux mondes qui semblent s'éloigner d'une certaine manière. Ceux qui comme nous fondent leur politique d'ingénierie réseau sur un pragmatisme total lié à la nécessité de fournir une qualité absolue à nos clients, et d'un autre côté ceux qui entendent marquer l'histoire d'Internet en France d'une pierre blanche pour leur satisfaction professionnelle. Tout cela est FORT regrettable et cela va se terminer -- assez misérablement pour le développement français -- avec un 10G au SFINX, à l'AMS-IX, au LINX et puis basta. Après tout, les prix plancher du transit et la qualité de ces derniers n'incitent plus à la diversification forcenée d'il y a 10 ans. On peut même considérer que la nébuleuse Orange perdue derrière les saturations diverses et variées d'Opentransit et constituée d'une armée de drones consommatrice de vidéos de chats sur Youtube n'incitent plus en cela. Salutations. -- Antoine Versini - Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] le FR-IX est ouvert
Sameh Ghane wrote: Je ne veux pas rentrer dans ce troll. Et tu as bien raison ! Quoiqu'il en soit à chaque extrémité de ces liens il conviendrait d'installer des équipements. Or tout un chacun sait pertinemment qu'il n'y a pas l'électricité dans le tiers-monde (ni l'eau courante.) Bonne journée à tous, -- Antoine Versini - Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: Ip publiques (was Re: [FRnOG] Pb OVH)
Clement Cavadore wrote: Ce fonctionnement là ne me choque pas. Si on a un subnet alloué pour le backbone, il faut bien qu'il soit public (ie: non RFC1918), mais si la communication avec l'extérieur du réseau n'est pas nécessaire (ce qui est généralement le cas avec les IPs d'interco interne au réseau, ou les loopbacks), alors pourquoi l'annoncer ? Disons que tu peux avoir communication si un routeur est amenné à proposer une fragmentation à l'éméteur du paquet qu'il détruit. Communication unidirectionnelle, certes, mais communication tout de même. Sur 5410 j'avais totalement filtré en entrant les classes servant à la numération des loopbacks et des /30 d'interco sur tout l'edge du réseau. C'est encore la moins pire des protections. Pour les probes venant de l'intérieur (les abonnés), une policy-map sur le control-plane est suffisante. Bref, on en revient à l'origine de la discussion, filtrer ICMP vers l'ensemble de ses blocs est inepte sachant que n'importe quel mioche peut trouver le switch UDP ou TCP de son botnet. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: Ip publiques (was Re: [FRnOG] Pb OVH)
Xavier Nicollet wrote: Le 29 avril 2010 à 11:28, Antoine Versini a écrit: Disons que tu peux avoir communication si un routeur est amenné à proposer une fragmentation à l'éméteur du paquet qu'il détruit. Communication unidirectionnelle, certes, mais communication tout de même. Le routeur prend-il l'ip de la loopback pour émettre l'icmp ? Il me semblerait plus logique qu'il utilise l'ip de l'interface de sortie. Le comportement standard est bien d'utiliser l'adresse IP (principale pour un certain vendeur ;) ) de l'interface par laquelle s'est présenté le paquet détruit. PS: je ne pensais pas particulièrement aux loopbacks quand j'ai posté. Ok. -- Antoine Versini Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Pb OVH
Julien Reveret wrote: Je ne comprend pas ce genre de stratégie, je veux bien être le candide à qui on a besoin de faire un dessin pour comprendre Le problème des 2 litres d'eau dans la carafe d'un litre, le filtrage n'y change rien, il n'y a pas besoin de dessin pour le comprendre :) Et encore, ça risque d'être un choc culturel pour le monsieur quand il va s'apercevoir avec effroi qu'après avoir trouvé le bidule parfait pour caser la flotte, il va se faire soumettre sa carafe avec de la bierre. Bierre qu'il n'aura par ailleurs aucun moyen de filtrer puisque c'est précisément le breuvage qui intéresse ses clients. -- Antoine Versini Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Free : ne m'appelez plus FAI
Jérôme Nicolle wrote: Comment pouvez vous vous prétendre fournisseur d'accès à *Internet* Je propose Fournisseur d'Accès au Contenu Télévisuel Unicasté sur Réseau Étranger (comprendre : depuis Youtube vers de la collecte FT DSL Access). Ça donne FACTURE. -- Antoine Versini Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Choix interface de livraison offre DSLE
Agnès Robert wrote: Bonjour, Je suis à la recherche d'informations au goût du jour sur les pro/cons concernant les deux types d'interface de livraison d'une porte DSLE France Télécom (ATM ou GigaE) aujourd'hui : dans le passé, j'ai essentiellement vu des livraisons en ATM, mais aujourd'hui? Est ce que les opérateurs restent sur la valeur sûre ATM, ou y en a t il de plus en plus qui passent sur Ethernet? Et pour quelles raisons? Simplement économiques (un port Gigabit coute moins cher qu'une carte STM1), ou autres? Merci d'avance pour toute info ! Bonjour, Pour ce qui nous concerne (Nerim), nous ne collectons les accès DSLE et CE2O qu'en ATM. Nous disposons à l'heure actuelle de 5 portes ATM en STM-4, et l'on peut dire que la qualité et la stabilité sont exemplaires. Dès qu'il s'agit de se faire livrer des circuits avec une véritable capacité garantie, que se soit en SCR différent du PCR ou voire-même en CBR pour les clients les plus exigeants, la question concernant le choix ATM ne se pose guère. L'on peut toujours argumenter sur la capacité d'Ethernet de reproduire ce type de schéma, soit en produisant des LSP dédiés à chaque liaison sur un réseau MPLS avec extensions TE activées et gestion de la CoS de bout-en-bout, mais aujourd'hui, quel opérateur l'a réellement fait si ce n'est pour faire du strict-priority queueing de sa classe de service associée à la VoIP ? Une porte de collecte en Ethernet c'est : - Pas d'OAM, donc impossible de connaître l'état du SDSL du client via signalisation, - Une belle interconnexion layer 2 dans laquelle il va faloir se prémunir des vicissitudes imposées par les différentes moutures de Spanning-Tree avec, cerise sur le McDo, des spécificités constructeurs, - Perdre la flexibilité de tous les contrats de trafic ATM disponibles, - Devoir jongler avec des configuration WRED souvent peu adaptables entre différents équipementiers, et aussi potentiellement devoir subir les spécificités du Q-in-Q d'untel ou autretel et de grossir les MTU à droite ou à gauche, - Ne parlons pas des scénarii Bollywoodiens dans lesquels les redondances entres portes sont réalisées par 802.1w. Ethernet a-t-il seulement été réellement conçu pour réaliser de véritables interconnexions entre opérateurs ? Dans un souvenir lointain cela servait à construire des réseaux multipoints très localisés. Quant à la question du coût, il suffit de chercher sur le gray market un LS1010 avec deux WAI-OC3-4MM et un 7200 avec une PA-A3-OC3, pour se rendre compte qu'il est absolument dérisoire, donc cet argument en faveur d'Ethernet n'est pas spécialement valide non plus. Il est vrai que l'on peut toujours dire que c'est une technologie du passé car -horreur- elle a plus de dix ans. Mais là encore, Ethernet a aussi largement plus de dix années de mauvais services... -- Antoine Versini Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Nerim / Orange : Time out
Alexandre NEY wrote: Bonjour à tous, Rencontrez-vous actuellement des problèmes de connexion entre Orange (ligne perso) et Nerim ? Certains de nos collaborateurs ne peuvent pas se connecter à nos services (webmail / vpn) alors que tout fonctionne bien depuis un autre ISP. D'avance merci pour vos retours et bonne journée, Bonjour, Pourriez-vous me communiquer les classes dans lesquelles se trouvent les adresses IP de vos concentrateurs de services de réseaux privés situés dans le réseau d'Orange, svp ? Off-list éventuellement. Merci beaucoup, -- Antoine Versini Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
