Re: [FRnOG] [MISC] Retours d'expérience pour présentation sur IPv4/IPv6
y. Il faut mettre à jour le téléphone avec une version de firmware récente pour qu'il puisse se provisionner en IPv6. - Epson Workforce (imprimante multi-fonction): le scanner ne fonctionne pas en IPv6 (le process scanner de l'imprimante n'écoute pas en IPv6) alors que tout le reste fonctionne parfaitement en IPv6. - Sur de nombreux produits j'ai vu le client DNS, SNMP, syslog,... fonctionner uniquement en IPv4 et donc cela pose problème dans un environnement IPv6 only. Je peut comprendre que beaucoup de personnes baissent les bras sur le déploiement d'IPv6 only car a chaque produit on essuie les platres car l'IPv6 n'est pas testé avec au temps de rigueur que l'IPv4. > * Les acteurs de l'internet ont-ils pris conscience des problèmes > avec IPv4 ? Sont-ils préparés à la pénurie d'IPv4 ? Les gros acteurs ne sont pas impactés car ils ont les moyens d'acheter des adresses IPv4. Temps qu'une loi n'imposera pas l'usage de l'IPv6, les acteurs de l'Internet ne bougeront pas sauf il y a une killer application ou un acteur tel que Google qui décrète que ses services ne seront plus accessible en IPv4. > * Que pensez-vous de l'utilisation du CG-Nat par les opérateurs ? C'est une abération totale. Pourquoi faire des solutions complexes usine à gaz qui introduisent d'autres problèmes ? L'énergie mise dans le CG-Nat devrait être mise dans l'IPv6. > * Les médias reflètent-il bien la vision des acteurs du réseau ? > (Je pense à cet article, qui avait fait grand débat : > https://www.lemagit.fr/actualites/252468059/Penurie-IPv4-comment- > lInternet-europeen-sombre-dans-les-magouilles) Les médias ne reflètent pas du tout correctement la vision des acteurs du réseau concernant la pénurie de l'IPv4. Tout le monde oublie une chose: la pénurie de l'IPv4 n'affecte pas ceux qui ont le pouvoir sur Internet et sur le monde numérique. En pratique, la pénurie est subit de plein fouet par les petits acteurs. De plus beaucoup de constructeur de matériel et d'éditeur logiciel font aucun effort pour supporter pleinement l'IPv6 (c'est à dire IPv6 only parfaitement fonctionnel sans dépendance d'IPv4). Trouvez-vous normal que en 2019 des routeurs 4G fraîchement sortis ne supportent pas pleinement l'IPv6 ? > * Que pensez-vous de la revente d'IPv4 ? C'est un business comme > un autre, ou à la limite de la légalité ? Comme tout commerce, temps qu'il y aura des acheteurs, il y aura des vendeurs. On peut imaginer assimiler les adresses IP à des ressources naturelles. Certains continents ont plus de ressources (or, pétrole, uranium,...), c'est pareil pour les adresses IP. La revente d'adresses IPv4 va devenir un frein pour beaucoup de petits acteurs pour se lancer ou se développer car le prix de l'adresse IPv4 va devenir de plus en plus important au fil du temps qui passe. Les RIR auraient du imposer le déploiement d'IPv6 (= serveur DNS, serveur mail, serveur Web accessible en IPv6) pour donner des adresses IPv4 supplémentaires depuis plus de 10 ans. > Si vous avez des commentaires, des retours d'expériences, et un avis > à donner en plus des questions, n'hésitez pas ! Si tu veut m'interviewer sur le sujet IPv6, n'hésite pas, comme tu peut le voir, j'ai plein de chose à dire sur le sujet ;) Le sujet IPv6 étant très vaste, je pourrais écrire un livre sur le sujet... -- Nicolas DEFFAYET Consultant architecte réseau spécialiste IPv6 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Firewall isofonctionnel IPv6 et IPvDépassé
On Thu, 2019-08-15 at 20:33 +0200, Radu-Adrian Feurdean wrote: > Demandez a vos stagiaires de tester du v6-Only. D'ailleurs c'est en déployant de l'IPv6 only que l'on s’aperçoit que souvent le support IPv6 n'est pas aussi fonctionnel que celui IPv4... Quelques exemples: - Téléphone SNOM 821: pas de default gateway IPv6, donc si le serveur HTTP & SIP n'est pas dans le même LAN, impossible d'utiliser le téléphone - Téléphone Cisco: pas de support IPv6 dans le firmware livré d'usine, donc il faut mettre à la main le firmware à jour en IPv4 si on souhaite déployer le téléphone dans un environnement IPv6 only - Imprimante multi-fonction EPSON: on peut tout faire en IPv6 sauf utiliser le scanner (j'ai jamais compris pourquoi EPSON n'avait pas implémenté l'IPv6 dans la partie scanner) Les constructeurs sont demandeur des remontés de bugs ou des ratés dans leur implémentation IPv6. J'avais remonté à l'époque à Supermicro que l'adresse IPv6 statique configurée manuellement pour l'IPMI n'était pas conservée lors d'un reset du module IPMI. Ils l'ont fixé et ce même pour des cartes mères qui n'était plus commercialisées. -- Nicolas DEFFAYET --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Firewall isofonctionnel IPv6 et IPvDépassé
On Thu, 2019-08-15 at 08:57 +0200, Denis Fondras wrote: Hello, > OpenVPN n'est pas configurable en IPv6-only : "The field IPv4 Tunnel > network is > required.". Le support IPv6 only dans OpenVPN est prévu pour la version 2.5. Plus de détail concernant la feature request: https://community.openvpn .net/openvpn/ticket/208 -- Nicolas DEFFAYET --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] MCAS
On Sat, 2019-05-11 at 18:27 +, Michel Py wrote: > Les commandes de vols électriques qui ont toujours priorité sur le > pilote. > La philosophie de Boeing est que c'est toujours le pilote qui a le > contrôle. > Airbus, c'est la bécane qui pilote, et si l'humain est pas d'accord, > démerdes toi le ciel t'aidera, ou pas. Dans l'amerrissage sur l'Hudson, la machine a joué un role clef en empêchant le pilote de faire sortir l'avion de son domaine de vol. Il ne faut pas oublier que l'humain est beaucoup plus lent que la machine dans les calculs et la réaction. -- Nicolas DEFFAYET --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] AS /22 à vendre
Bonjour Xavier, Je suis désolé que votre projet n'ai pas décollé. A quel prix cédez-vous le /22 ? Merci Cordialement, On Wed, 2018-12-05 at 08:11 +0100, Xavier Lemaire wrote: > Bonjour > > Si vous avez besoin d'un /22 je cède l'AS205000 car le projet qui y > était > attaché n'a jamais décollé. > > bien cordialement > > -- Nicolas DEFFAYET --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [BIZ] Matériel à vendre
Bonjour à tous, En cette saison estivale, j'ai du matériel à vendre: - 1x onduleur APC Smart-UPS 2200 LCD SMT2200RMI2U (pas d'expédition possible, à venir chercher sur Levallois-Perret, prévoir un changement de batterie l'onduleur coupe l'alimentation des équipements secourus quand on exécute le self-test) - 1x routeur Mikrotik CCR1036-12G-4S-EM avec 2x SFP Mikrotik 1000LX - 1x borne Wi-Fi Cisco Aironet 702i AIR-SAP702I-E-K9 - 1x switch TP-Link TL-SG3216 neuf dans son emballage - 1x switch TP-Link TL-SG3216 d'occasion - 2x téléphone IP Snom 821 avec leur bloc d'alimentation 220V (je les vends car ils ne sont pas pleinement utilisable dans un environnement full IPv6) Faites vos offres en me répondant en privé. Bon week-end à tous. -- Nicolas DEFFAYET --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Microsoft (ASN 8075) sur AMS-IX
On Mon, 2017-07-10 at 12:22 +0200, Fabien H wrote: > J'ai du mal à comprendre pourquoi certains peers n'utilisent pas > les RS alors qu'il acceptent le peering direct ? Pour des questions de > sécurité BGP ? Beaucoup d'acteurs n'utilisent pas les route-servers pour plusieurs raisons: - Le fait qu'en cas de problème de niveau 2 partiel, le routage ne basculera pas car les routes seront toujours apprisent par le route-server (pour rappel, la session BGP est établie avec le route-server mais ce dernier envoie un next-hop différent). - Le fait qu'une session BGP directe avec un peer est plus simple à superviser permettant de savoir très facilement si un peering est down. - Si un peer ne crée pas des objets route/route6 corrects, la route ne sera pas transmise par le route-server alors qu'elle le serait sur une session BGP directe - Du jour au lendemain, un peer peut arrêter d'utiliser le route-server - Une question de responsabilité, en effet avec une session BGP directe, en cas de problème, le responsable est très vite désigné, alors qu'avec un route-server c'est plus compliqué. Il y a aussi des acteurs qui n'annoncent pas les même routes sur les sessions BGP directes et les route-servers. Dans tous les cas, quand le peer est important, il est préférable de monter une session BGP directe avec lui. -- Nicolas DEFFAYET --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Microsoft (ASN 8075) sur AMS-IX
On Mon, 2017-07-10 at 12:08 +0200, David Ponzone wrote: > Juste pour info, c’est comme ça sur EQNX-IX, mais c’est normal: ils n’ont > jamais annoncé leurs routes par le MLPE. Microsoft a pour politique de ne pas utiliser les route-servers, et ce quelque soit le point d'échange. "Microsoft will not be peering with Route Servers going forward" Pour l'établissement d'une session BGP directe avec Microsoft, il faut remplir leur formulaire disponible à l'adresse suivante: http://www.microsoft.com/peering -- Nicolas DEFFAYET --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Contacts commerciaux equinix / Telehouse 2
On Thu, 2017-03-09 at 17:46 +0100, Jeremy wrote: Bonjour Jeremy, > Avez vous un contact à partager pour une location de baie sur Telehouse > 2 et/ou sur Equinix PA3 ? Stéphane Leprince-Ringuet Stephane.Leprince-Ringuet AT eu.equinix.com +33 1 49 97 30 34 +33 6 22 46 01 71 A bientôt -- Nicolas DEFFAYET --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Article du Point sur la cyberguerre
On Fri, 2017-02-10 at 16:30 +0100, Stephane Bortzmeyer wrote: > Il parle d'un centre situé « quelque part dans Paris » qui abrite un > « bâtiment ultrasécurisé [...] 14 000 mètres carrés d'équipements > vitaux pour l'Internet français ». Bon, je vous laisse deviner de quoi > il s'agit (le Point, pour faire croire qu'ils connaissent des secrets > d'État, ne donne pas le nom de ce mystérieux centre) mais ma question > portait sur un autre chiffre « 80 % du trafic direct [?] métropolitain > passe par là ». > > Quelqu'un a une idée de l'origine, de la méthodologie, et de la > véracité de ce chiffre ? Le chiffre des m2 a été doublé par rapport à ce que ce datacenter annonce sur son propre site Web: "Avec un espace total en colocation de 7 000 m2 [...]" Concernant le traffic métropolitain, c'est encore à minima doublé pour plusieurs raisons: - ils ont 2 confrères avec un très grand nombre de m2 et il y a énormément de traffic qui ont pour origine les m2 de ces confrères - les gros opérateurs eye-balls échangent la majorité de leur traffic dans leur propre datacenter ou est situé leur coeur de réseau Personne ne peut dire sur le marché, j'ai x % de traffic d'Internet métropolitain/mondial/etc... En effet, il est impossible de savoir le volume de traffic qui passe dans les fibres noires qui servent pour les interconnections privées. Le volume de traffic ne veut absolument rien dire, il faut regarder l'origine, l'usage et la valeur de ce traffic. La plus part du temps, c'est ce qui produit le moins de traffic qui a le plus de valeur. Un bon exemple: la platforme Megaupload à son heure de gloire vs le moteur de recherche Google. > Quelqu'un a une idée de l'origine, de la méthodologie, et de la > véracité de ce chiffre ? (Sinon, il va falloir que je scrape l'HTML > de <https://www.franceix.net/en/france-ix-paris/members-in-paris/> et > on aura au moins le pourcentage en capacité, à défaut d'avoir celui en > débit.) Les points d'échanges partout dans le monde, n'ont jamais été un indicateur pour estimer le niveau de traffic qu'il y a dans une ville. En effet, chaque ville a une proportion différente de traffic échangé entre point d'échange publique et interconnection sur fibre dédié. -- Nicolas DEFFAYET --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Discussion en cours au RIPE - besoin de mobilisation
On Fri, 2016-02-19 at 17:29 +0100, Frederic Dhieux wrote: Bonjour, > Je ne comprends toujours pas qu'en 10 ans qu'on prévoit la pénurie, > aucun effort n'ait été fait pour préparer la possibilité d'utiliser > 240.0.0.0/4 un jour. On se retrouve à réfléchir à des trucs compliqués > alors qu'un bloc "RESERVED Future use" d'il y a 27 ans ne sera jamais > exploité. 240.0.0.0/4 n'est pas utilisable sur beaucoup d'équipements et de logiciels car ces derniers ne reconnaissent pas 240.0.0.0/4 comme un adressage unicast valide. > Pourquoi pas les DNS root pour commencer ? En éteindre au fur et à > mesure en IPv4 et fermer le dernier à une date raisonnable d'ici 3 à 5 > ans ? Pourquoi ne pas ralentir les performances d'IPv4 en aillant une > latence légèrement dégradée vers ceux ci dans le temps ? (même si c'est > pas très beau, disons moins geo-multiplier ces serveurs en IPv4) Réduire les performances d'IPv4 est impossible, cela va à l'encontre des SLA des opérateurs. > A un moment de toute manière il va falloir motiver les gens autrement > que par des belles paroles, si leur business n'est pas en jeu, ils ne > bougeront pas. Pour certains ça semble un travail de fou alors qu'on > parle de mettre au pire un reverse proxy web, des dns et du mail en IPv6 > sur une plateforme IPv4. Un acteur comme Apple a fait bouger les opérateurs et a réussi à leur imposer de nombreuses choses. La killer-app IPv6, c'est l'éco-système Apple et Google. Si Apple et/ou Google décident qu'au 01/01/2020 il n'y a plus d'IPv4, tout le monde déploiera IPv6 car les opérateurs pousseront très fort en raison de l'impact business. > Peut-être des tutos massivement diffusés aux sites webs déjà aiderait > aussi sur la manière de mettre une couche IPv6 publique facilement sans > tout changer. Ce n'est pas un problème de tutos mais de support de l'IPv6 correct dans les équipements et logiciels. > Nous les opérateurs on est sensibilisés à tout ça, mais est-ce que ça > touche autant les sites finaux hébergés ce problème ? Parce qu'eux ils > n'y pensent pas trop et leur seul problème c'est de pas perdre du temps > sur ce qui ne rapporte pas de l'argent. Received: from m.syn.fr (m.syn.fr [195.154.64.190]) by cabale.usenet-fr.net (Postfix) with ESMTP id 5801798A5949 for <frnog@frnog.org>; Fri, 19 Feb 2016 17:31:16 +0100 (CET) Ton mail a été reçu en IPv4 ;) Ce n'est pas qu'une question de sensibilisation, énormément de personnes sont sensibilisées mais très peu déploie l'IPv6 en pratique. -- Nicolas DEFFAYET --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Discussion en cours au RIPE - besoin de mobilisation
On Fri, 2016-02-19 at 15:23 +0100, Alarig Le Lay wrote: Bonjour, > Pour favoriser le déploiement d’IPv6, on peut imaginer l’attribution de > nouveaux blocs IPv4 uniquement de l’IPv6 est déjà en production réelle > (pas comme chez SFR où il faut aller farfouiller dans la box pour > l’activer, ou pire des AS qui annoncent mais ne l’utilisent pas). Le problème est que chacun se renvoie la balle: - les fournisseurs d'accès Internet ne veulent pas activer l'IPv6 par défaut car ils ne veulent pas traiter les plaintes des utilisateurs qui auraient du mal à accéder à un fournisseur de contenu - les fournisseurs de contenu argumente le fait qu'ils ne voient pas l’intérêt de rendre leur services compatible IPv6 vu que les fournisseurs d'accès Internet ne sont pas compatible IPv6. Il faut prendre en compte aussi que ni les constructeurs de matériel ni les développeurs n'ont jamais favorisé l'usage de l'IPv6 par rapport à l'IPv4. Le pire c'est quand un constructeur dit que son équipement est compatible IPv6 mais que dans les fait l'équipement répond juste en ping IPv6 et qu'aucun service n'est compatible IPv6... Pour rappel il n'y a toujours pas de support DHCPv6 dans Android(1). Rien que cela, c'est un énorme frein. Un très grand nombre de déploiement IPv6 sont en DHCPv6 afin - d'avoir un dual stack consistant (DHCP v4/v6) - d'avoir un audit sur l'attribution des addresses (SLAAC n'a pas de feature d'audit et il n'est pas possible de loger l'attribution des adresses sans déployer une usine à gaz) - d'avoir une adresse fixe attribué en fonction de la MAC address sans que l'adresse IPv6 ne contiennent la MAC address - de communiquer l'adresses IPv6 des serveurs DNS (SLAAC RDNSS n'est pas compatible avec tous les clients!) - de ne pas donner une adresse à une machine inconnu (1) https://code.google.com/p/android/issues/detail?id=32621 http://www.techrepublic.com/article/androids-lack-of-dhcpv6-support-poses-security-and-ipv6-deployment-issues -- Nicolas DEFFAYET --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Coupure AS13193 = AS8560 ?
On Fri, 2015-05-29 at 18:49 +0200, Christophe wrote: Bonjour Christophe, Au départ, c'était de l' [ALERT] mais qui semble ne plus en être une ... Deux de nos clients ont remonté des coupures de services, visiblement entre ces deux réseaux (entre 17h50 et 18h20). Cas 1 : Réseau derrière une Fibre Nerim vers mails et serveur dédié chez 1And1. Cas 2 : Serveur à EQX/PA2 sur le réseau Nerim, qui dialogue en Webservices avec un serveur chez 1And1 . La coïncidence est assez troublante. Pendant cette période les deux réseaux étaient accessibles depuis les autres opérateurs. C'est remonté depuis, mais si quelqu'un a des infos à ce sujet. Sur les statistiques de traffic de Nerim visibles à l'adresse suivante http://stats.nerim.net/nav/internet/, on peut voir qu'il y a deux grosses chutes de traffic sur le DE-CIX. -- Nicolas DEFFAYET --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] GS - opérateur
On Sat, 2014-10-25 at 16:46 +0200, Sylvain Vallerot wrote: On 25/10/2014 12:47, Clement Cavadore wrote: On Sat, 2014-10-25 at 12:43 +0200, slesimple wrote: Propriété de DRT, en leasing par EQX. Alors pourquoi ca ne s'appelle pas Equinix PA5 par exemple ? PA2 et PA3 sont sur la propriété de DRT mais je crois que les installations appartiennent à Equinix (pas certain). Equinix loue uniquement les murs à DRT. Toute l'infrastructure est conçue et opérée par Equinix. Les installations appartiennent à Equinix. -- Nicolas DEFFAYET --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] GS - opérateur
On Sat, 2014-10-25 at 18:05 +0200, Sylvain Vallerot wrote: Mais bon, nous voilà assez loin de GS qui eux aussi semblent open sur la venue d'opérateurs et le développement d'interco. On voit bien la différence de positionnement et là où la neutralité joue. Equinix a toujours été open sur la venue d'opérateurs et le développement d’interconnexion. Si Equinix n'était pas open, le campus PA2/PA3 ne serait pas le datacenter avec la plus forte densité réseau derrière Telehouse 2. -- Nicolas DEFFAYET --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] GS - opérateur
On Sun, 2014-10-26 at 18:04 +0100, Sylvain Vallerot wrote: Et si vous me faites changer d'avis il y aura probablement bientôt une offre sympa de MMR sans pertes sur PA2 gérée par un opérateur d'opérateurs neutre. Une MMR sans perte cela n'existe pas, la seule façon de ne pas avoir de perte c'est un cable d'un seul morceau de bout en bout. Hors par définition dans une MMR, tu fait la jonction d'une cable venant d'un client A avec un cable venant d'une client B à l'aide d'un patch. Il y a aucun modèle de câblage parfait: MMR: + flexibilité + délai de mise en oeuvre d'un circuit rapide en raison du précablage + limitation au maximum du volume de cables dans le datacenter + un seul cable dans la baie client permet de connecter différents point dans le datacenter + point de demarc simple: le patch-panel dans la baie client - attenuation introduite par les différents points de coupures Câblage point à point direct (ce qui se fait sur Telehouse 2): + pas d'atténuation introduite sous réserve d'avoir un cable d'un seul morceau - délai de mise en oeuvre longs car pour chaque circuit il faut tirer un nouveau cable - grand volume de cables dans le datacenter - un cable par circuit dans la baie client Quasiment tous les datacenters récents utilisent un système de MMR (pour ceux utilisant la notion de 2 demi-circuits avec patch) ou d'ODF (pour ceux utilisant la notion d'un seul circuit complet mais qui est coupé par des ODF). D'ailleurs les points de coupures sur les circuit fibre ne sont pas spécifique au datacenters, les opérateurs proposant de la fibre noire ont le même problème. -- Nicolas DEFFAYET --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] - Hijack IndoSat / AS4761
On Wed, 2014-04-02 at 22:52 +0200, Laurent CARON wrote: Bonsoir Laurent, Recevez-vous aussi des alertes BGPMon à propos de vos préfixes annoncés par IndoSat (AS4761) ? Je reçoit également ces alertes. Il y a pour info un fil de discussion sur le sujet sur la mailing-list NANOG. -- Nicolas DEFFAYET --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Routeurs cisco
On Tue, 2014-02-25 at 18:41 +0100, Jérôme Nicolle wrote: Le 24/02/2014 21:53, noruja...@gmail.com a écrit : J'ai connu les mêmes problèmes avec un switch 3560G configuré en L3 (v4/v6) ospf et bgp. Le 3560G ne route pas le v6 en hard. Les 3560G routent l'IPv6 en hardware. Extrait de la datasheet: The Cisco Catalyst 3560 Series can be purchased with the IP Base or IP Services licenses pre-installed. The IP Base license offers advanced QoS, rate limiting, ACLs, and basic static and Routing Information Protocol (RIP) routing functions. The IP Services license provides a richer set of enterprise-class features, including advanced hardware-based IPv6 unicast and IPv6 Multicast routing as well as policy-based routing (PBR). http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-3560-series-switches/product_data_sheet09186a00801f3d7d.html C'est les 3550 qui ne supportent pas l'IPv6 en hardware malgré la disponibilité d'une version IOS compilé avec le support IPv6. -- Nicolas DEFFAYET --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Re: Panne élec Global Switch Clichy, RDC
Hello, Il y a une panne electrique generale sur Levallois depuis plus de 15min. Cyril Bouthors cy...@bouthors.org wrote: On 1 Dec 2012, cy...@bouthors.org wrote: Depuis 20 mins. HIH Yet again, même panne, même endroit. Coupure de 4h55 à ~5h55 -- Cyril Bouthors - Administration Système, Infogérance ISVTEC SARL, 14 avenue de l'Opéra, 75001 Paris 1 rue Émile Zola, 69002 Lyon Tél : 01 84 16 16 17 - Fax : 01 77 72 57 24 Ligne directe : 0x7B9EE3B0E --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Nicolas DEFFAYET --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Re: Compte à rebours des 400 000
On Sat, 2012-08-18 at 01:14 +0200, Olivier Benghozi wrote: Hello, Ça va du faut filtrer tout ce qui est plus petit qu'un /21 à voilà les allocations selon les pools IANA, faut prévoir 250 lignes de prefixlist, et bien sûr on peut tenir compte de peering/je garde, transit/je filtre et je default au moins partiellement. Le filtrage sur le minimum allocation size des RIR n'est plus possible malheureusement car l'ARIN et le RIPE ont réduit leur minimum allocation size à /24 pour leur blocs IANA. ARIN: Tous leurs blocs IANA sont à /24. http://www.apnic.net/db/min-alloc.html ARIN: 7 blocs IANA sont à /24 actuellement, ils réduisent progressivement le minimum allocation size des autres blocs IANA en fonction des allocations/PI assigment qui se libèrent et des demandes. http://www.arin.net/reference/ip_blocks.html RIPE: The smallest prefix assigned by the RIPE NCC from any IPv4 range is a /29. https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html LACNIC: Pour le moment seul 1 bloc IANA est à /24, les autres sont toujours à /22 comme initialement. http://lacnic.net/en/registro/index.html AFRINIC: La page retourne un 404. http://www.afrinic.net/Registration/resources.htm Le problème sur le filtrage est l'importance du prefix ou de l'AS. Il peut y a avoir des /24 très critiques (comme les root DNS server) ou des sites de contenu très important qui ont un /24 PI. Personnellement, je réfléchi plus à la construction de prefix-list basées sur la criticité que par rapport à la taille du prefix. Après une prefix-list de 250 lignes, c'est rien. Pour rappel de nombreux réseaux générent des prefix-lists automatiquement depuis les AS-MACRO pour tous leurs peerings. Un concept qui serait efficace pour plusieurs choses (filtrage de route, QoS,...), c'est que chaque réseau déclare les adresses IP/prefixes utilisés pour des services critiques dans la base du RIR pour pouvoir construire des prefix-lists automatiquement. Cela permettrai aussi d'aider dans la décision de mise en place de peering, car malheureusement beaucoup de décision sont prise sur un niveau de traffic et non pas sur la criticité d'un service ou sur l'intérêt du service proposé (exemple1: un content provider qui refuse de peerer avec un eye balls provider car il n'y a pas beaucoup de traffic, sauf que cet eye balls provider à que des clients professionnel qui font peu de surf et que du mail - exemple2: les contents providers et les eye balls provider qui refusent de peerer avec les DNS root server (F ISC, M WIDE,...) car le traffic est trop faible (c'est normal que le traffic soit faible car c'est que du traffic DNS mais ce dernier est hautement critique)). Ceux qui ont vraiment tout plein beaucoup de routes ont dû lâcher les archis à base de TCAM. Indépendamment du nombre de routes, ce qui s'est vendu comme des ptits pains après l'époque du 6500, ce sont les MX de Juniper. Pas de TCAM là-dedans pour la FIB, plusieurs millions de routes supportées. D'ailleurs en matière de VPNv4, sur les 6500 dans la TCAM, par défaut (et jusqu'à ce que le Per-VRF Label soit disponible -quoique expérimental- sur 6500), une route VPNv4 compte double (une entrée dans la partie IPv4, une dans la partie MPLS), tout comme une route IPv6 (et une route VPNv6 compte triple). La plate-forme Cisco 6500/7600 est utilise par énormément de réseaux (quelque soit la taille, y compris des gros) comme routeur edge pour livrer leur clients. Je ne les voit pas changer du jour au lendemain tous leurs routeurs car la DFZ ne rentre plus dans la TCAM de leur routeur edge. Beaucoup vont déployer des route-servers et ils vont donc monter les sessions BGP en multi-hop avec leur client. -- Nicolas DEFFAYET --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Re: Compte à rebours des 400 000
On Sat, 2012-08-18 at 03:09 +0200, Jérôme Nicolle wrote: Le 18/08/2012 00:30, Clement Cavadore a écrit : La question à se poser est surtout: pourquoi maintenir une full route, si le coeur de métier n'est pas de vendre du transit BGP derrière ? Ou alors, pourquoi rentrer une full view au chausse pied dans un routeur alors qu'un route server suffit, ou plus simplement de généraliser l'eBGP multihop. Il n'y a malheureusement pas à ma connaissance aujourd'hui de solution clé en main, à très faible coût, avec support, et fiable sur le marché pour déployer des routes-servers ayant une capacité de calcul très rapide pour limiter les temps de convergences. D'ailleurs, l'un d'entre vous pourrait il me dépanner d'un p'tit 6500 avec une SUP720-3B, ou une SUP32, pour faire quelques tests d’agrégateur externe ? Tu peut nous en dire plus sur les tests que tu veut effectuer ? -- Nicolas DEFFAYET --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] recherche châssis rack 2 ou 3u avec 10 slots HDD SAS/SATA
On Thu, 2012-03-01 at 17:47 +0100, Damien Fleuriot wrote: Hello Damien, Je galère un peu à trouver un châssis 2 ou 3u à un prix abordable. J'ai un magnifique nas à la maison avec 9 disques SATA 3.5 et 1 SSD 2.5 pour l'OS, dans une (grande) tour. La carte mère uATX de 10x10 semble largement tenir dans ce genre de châssis. Je veux bouger tout ça dans un châssis 2u ou 3u mais je tombe sur des boîtiers à 900-1000 euros avec l'alim. Tu trouvera peut être ton bonheur sur: http://www.xcase.co.uk/ ou http://www.servercase.co.uk/ ou http://cybershop.ri-vier.nl/ -- Nicolas DEFFAYET --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] augmentation table de routage BGP et gestion de celle-ci sur les routeurs
On Fri, 2011-12-23 at 17:08 +0100, Raymond Caracatamatere wrote: Bonsoir Raymond, Depuis la pénurie d'IPv4, la table BGP augmente chaque jours plus vite qu'avant, aujourd'hui à 38 routes les routeurs nous rappellent à l'ordre. Hormis la solution de filtrer les annoncent /24 et de poser une default gw vers les transitaires, avez-vous d'autres solutions ? Si tu filtre et que ton routeur n'a plus de full table BGP, il est impératif que tes transitaires t'annonces 0.0.0.0/0 en BGP. En effet, si tu ne fais pas cela, certaines destinations seront injoignables. Il faut garder à l'esprit qu'en filtrant, tu n'aura plus d'information sur les AS dans les statistiques Netflow sur tes transitaires. Tu as plusieurs possibilités de filtrage sur tes transits: Option 1: Filtrer sur le minimum allocation size Il ne faut pas oublier également que certains LIR annoncent leur allocation uniquement de manière désagrégée (ex: /23) sans annoncer l'allocation tel quel a été attribuée (ex: /19). Inconvénients: - Les RIR vont a terme mettre leur minimum allocation size à /24 ce qui limitera l'efficacité de cette méthode. L'APNIC le fait depuis plus d'un an déjà. - Cette méthode ne permet pas de descendre en dessous de 200 000 routes donc à oublier pour les SUP2, SUP32, SUP720(non XL),... - prefix-list longue Option 2: Filtrer sur /19 et accepter les prefixes critiques Inconvénients: - Les réseaux qui ont un bloc d'adresses IP de taille inférieur à /19 passe à la trappe. Les réseaux ne sont donc pas tous égaux car il peut y avoir des petits réseaux très important mais qui ont uniquement un /23. - La définition de prefixes critiques est sujet à de long débats: est-ce uniquement les prefix des DNS root ? inclus-t-on les serveurs gérant les CCTLD ? - Il faut mettre en place un process pour mettre à jour la liste des prefix critiques pour faire les choses proprement même si au pire des cas, cela passe par la default-route. Option 3: Accepter uniquement les prefixes critiques Avantages: - Tous les réseaux sont égaux, chacun est visible par une default route. Inconvénients: - Impossible de faire du traffic engineering et de répartir le traffic sur différents transitaires. Il ne faut pas oublier que pour gérer un grand nombre de routes, un routeur n'a pas besoin uniquement de mémoire (RAM / TCAM) mais il a besoin aussi de beaucoup de CPU pour que la convergence des routes soit la plus rapide possible sans impacter les autres services du routeur. Je ne connais pas beaucoup de réseaux prêt à investir dans des routeurs haut de gamme pour supporter une full table de 1-2 millions de routes IPv4 (en plus des 100 000 routes IPv6 quand chaque ASN annoncera son bloc IPv6) avec un temps de convergence correct qui n'impacte pas les autres services du routeur juste pour avoir le luxe d'avoir une full table. De nombreux réseaux vont devoir se priver de full table pour des raisons économiques. La taille de la table de routage de Internet IPv4 peut être un long débat. -- Nicolas DEFFAYET --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] 2006-01 - Provider Independent (PI) IPv6
On Wed, 2009-05-06 at 12:15 +0200, Clement Cavadore wrote: Xavier Beaudouin wrote: C'est la seule chose que me bloquais en tant que association 1901 pour déployer de l'IPv6 (a part le matériel ... mais c'est autre chose). +1. Même si j'ai utilisé du PA en attendant (qui a forcément le même effet que du PI, en multihomé...) End User Assignment Agreement: http://www.ripe.net/ripe/docs/ripe-462.html Upon signature of this Agreement, the End User shall pay to the RIPE NCC an Administration Fee. During the term of the Agreement, the End User shall pay a periodical Maintenance Fee. The fees are defined annually by the RIPE NCC General Meeting as part of the Charging Scheme and shall be published at www.ripe.net. The End User shall pay the Administration Fee and Maintenance Fee within 30 days of the date of the invoice, failing which the End User shall be in default with no notice of default being required. RIPE NCC Charging Scheme 2009: http://www.ripe.net/ripe/docs/ripe-437.html Upon conclusion of the End User Assignment Agreement, the End User shall pay to the RIPE NCC an Administration Fee, equal to the Sign-up Fee for new members. During the term of the agreement, the End User shall pay a periodical Maintenance Fee based on End User’s billing category. An End User’s billing category is set based on the End User’s Billing Algorithm score. This score is based on the Internet number resource allocations and assignments made over time at the End User’s request. The scoring system takes into account all: - IPv4 Provider Independent (PI) assignments - IPv6 PI assignments - AS Number assignments For new End Users the billing category will be Extra Small for the first year. http://www.ripe.net/membership/billing/procedure-enduser.html Donc pour un client qui veut un PI IPv6 ca va lui coûter: Setup: 2000 EUR 1ere année: 1300 EUR PS: C'est maintenant applicable aussi pour les PI IPv4 et les ASN. Donc pour conclure, ca coute moins chère d'avoir un PA IPv6 que un PI IPv6 ;) -- Nicolas DEFFAYET --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] AS 32 bits et cisco
On Wed, 2008-09-24 at 17:04 +0200, Salim Gasmi wrote: Salut Salim, Comme les AS a 4 octets vont bientot faire leur apparition debut 2009, et que je n'ai que moyennement envie de voir des AS23456 partout dans nos tables de routage, je me demandait si cisco avait deja sorti un IOS qui supporte les AS 32bits . En particulier pour les 7600/6500, je n'ai rien trouvé sur le site cisco .. Il y a une roadmap à l'avant-dernier slide: http://www.menog.net/meetings/menog2/presentations/philip-smith-32bit-asn.pdf -- Nicolas DEFFAYET --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Telia/Cogent split
On Sat, 2008-03-15 at 02:46 +0100, Manuel Guesdon wrote: FYI, récupéré de nanog: http://gigaom.com/2008/03/14/the-telia-cogent-spat-could-ruin-web-for-many/ Effectivement, on ne reçoit plus d'annonces telia de cogent... Qui joue le gros méchant ? Les 2 ? Chez Cogent, il arrive que le peering manager s'engage sur quelque chose qui au final ne fait pas (par exemple: upgrade d'un peering). De plus si ce dernier est contrarier (escalade à son supérieur), il n'hésite pas à dépeerer. Je parle de cela en connaissance de cause, car c'est du vécu. -- Nicolas DEFFAYET --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Matériel Cisco 6500 / Multiplexeur
Bonsoir, Désolé si mon message est un peu hors-sujet. Je recherche actuellement les éléments suivants d'occasion: 1x Cisco Catalyst 6009/6509 Fan Tray High speed: WS-C6K-9SLOT-FAN2 ou Cisco Catalyst 6009/6509 Fan Tray Classic: WS-C6K-9SLOT-FAN 2x Cisco Catalyst 6000/6500 Power supply AC 1300W: WS-CAC-1300W 1x Cisco Catalyst 6000/6500 Supervisor Engine Card 1 with MSFC2: WS-X6K-S1A-MSFC2 2x 1310/1550 Wavelength Division Multiplexer (le plus simple le moins chère) Si quelqu'un peut me vendre ces éléments à tarif très intéressant, merci de me contacter en privé. -- Nicolas DEFFAYET NDSoftware http://www.ndsoftware.com/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Freeix Province
On Wed, 2004-01-07 at 15:07, Hosting France [A. Turpin] wrote: Bonjour, Quelqu'un aurait plus de précision sur le montage d'un FreeIX en province ? Il parait qu'il est prévu que FreeIX soit disponible dans tous les POPs LDCOM. (un article sur usenet confirme l'info: http://groups.google.fr/groups?q=ldcom+freeix+group:fr.reseaux.internet.hebergementhl=frlr=ie=UTF-8selm=3efde862%240%2426591%24626a54ce%40news.free.frrnum=1) Mais bon, je ne trouve pas cela intéressant, car bon un POP comme Lille ne doit pas raporter beaucoup de membres. A la limite on pourrait dire Lyon, mais il y a le Lyonix (http://www.lyonix.net)... Donc personnellement, je ne trouve pas qu'un POP dans une ville de province soit intéressant. -- Nicolas DEFFAYET, NDSoftware NDSoftware IP Network: http://www.ip.ndsoftware.net/ FNIX6 (French National Internet Exchange IPv6): http://www.fnix6.net/ EuroNOG: http://www.euronog.org/ Liste de diffusion du FRnOG http://www.frnog.org/ --- Archives : http://www.frnog.org/archives.php ---
Re: [FRnOG] EBGP pour transporter prefixes v4 et V6
On Thu, 2003-10-30 at 11:22, Vincent Gillet wrote: Quel est le best-practice des opérateurs 100% dual-stack tant en ce qui concerne I que EBGP ? . Une session V4, un session V6 ? Ca fait les sessions en double IMO . Une session qui transporte les 2 ? Ca semble plus simple aux premiers abords, surtout pour l'IBGP. Peut être est-ce moins robustes (genre update v6 foireu qui plante la sessions, donc la connectivité v4 aussi) C'est une session IPv4 + une session IPv6, soit 2 sessions au total. On ne peut pas à ma connaissance transporter des routes IPv6 dans une session BGP IPv4 et inversement. -- Nicolas DEFFAYET, NDSoftware NDSoftware IP Network: http://www.ip.ndsoftware.net/ FNIX6 (French National Internet Exchange IPv6): http://www.fnix6.net/ EuroNOG: http://www.euronog.org/ Liste de diffusion du FRnOG http://www.frnog.org/ --- Archives : http://www.frnog.org/archives.php ---
[FRnOG] Nettoyage connecteur fibre SC sur équipement
Salut, Quelqu'un connait-il une meilleur solution que le cotontige spécial nettoyage fibre optique pour le nettoyage de connecteur fibre SC sur équipement (donc c'est la partie femelle) ? Qui aurait des adresses pour acheter ces cotontiges spécial nettoyage fibre optique ? (de préférence en France pour une livraison rapide) Merci -- Nicolas DEFFAYET, NDSoftware NDSoftware IP Network: http://www.ip.ndsoftware.net/ FNIX6 (French National Internet Exchange IPv6): http://www.fnix6.net/ EuroNOG: http://www.euronog.org/ Liste de diffusion du FRnOG http://www.frnog.org/ --- Archives : http://www.frnog.org/archives.php ---
Re: [FRnOG] BGP avec PC + zebra ?
On Fri, 2003-09-12 at 17:53, Nicolas Cartron wrote: Merci pour ces infos, neanmoins il s'agirait d'une utilisation avec des liens giga, Zebra supporte ca sans probleme ? Zebra s'occupe uniquement du routage, c'est un userland. Pour le support de lien giga, c'est au niveau du système d'exploitation et du matériel. Un PC sous FreeBSD supporte sans problème des liens giga avec le matériel qui va bien. Par contre pour le giga, il ne faut pas oublier la limitation de bande passante du bus PCI -- Nicolas DEFFAYET, NDSoftware NDSoftware IP Network: http://www.ip.ndsoftware.net/ FNIX6 (French National Internet Exchange IPv6): http://www.fnix6.net/ EuroNOG: http://www.euronog.org/ Liste de diffusion du FRnOG http://www.frnog.org/ --- Archives : http://www.frnog.org/archives.php ---
Re: [FRnOG] Transit FT et Catalyst 3550
On Tue, 2003-02-04 at 22:07, Arnaud Turpin wrote: Bonjour, - Quelqu'un sait si FT vend du transit dans un centre de colocation pour ne pas avoir les frais de construction de ligne ? (Parix c'est uniquement du peering ? ils y vendent du transit aussi ?) Il me semble que FT vend du transit au Parix. - Petite question si quelqu'un a un Catalyst 3550 EMI de chez cisco Peut on s'en servir aussi pour etablir des sessions bgp ? Sur la doc il semble que oui mais avec 64 Mo RAM ça ne doit pas aller bien loin. Nbre maximum de préfix ? Une full table BGP IPv4 ca fait dans les 190MO, donc pas assez de mémoire. -- Nicolas DEFFAYET, NDSoftware NDSoftware NOC: http://noc.ndsoftwarenet.com/ FNIX6: http://www.fnix6.net/ EuroNOG: http://www.euronog.org/ Liste de diffusion du FRnOG http://www.frnog.org/ --- Archives : http://www.frnog.org/archives.php ---
Re: [FRnOG] Un point d'échange IPv6 200%gratuit en France
On Mon, 2003-02-03 at 22:03, Stephane Bortzmeyer wrote: On Friday 10 January 2003, at 18 h 48, Nicolas DEFFAYET [EMAIL PROTECTED] wrote: Raphit à savoir au FNIX6 il n'y a personne Raphit il n'y a qu'en publiant ta liste que tu lèveras ce doute dans la tête des gens = La liste sera publier avant la fin du mois. Ouaf, ouaf. Trop occupé à gonfler la baudruche Euronog ? Au lieu d'imiter Milou, tu devrait t'occuper de tes affaires. http://www.01net.com/article/189587.html A Paris, un accès rapide pour 30 euros Place Net, qui démarre en septembre, va proposer un accès vingt fois plus rapide que l'ADSL à 4000 privilégiés du XIe arrondissement à Paris. [...] Le projet sera lancé dans le XIe arrondissement dès septembre, avec 4 000 prises, et devrait être étendu à partir de 2003 pour atteindre 72 000 connectés en fin d'année. Trop occupé à chercher la petite bete dans les projets de NDSoftware ? Il y avait longtemps, Placenet avait annoncé des accès ADSL, bien sur ces derniers n'ont jamais vu le jour. Il y a un peu plus de 6 mois, Placenet announce la création d'un MAN parisien, bien sur ce dernier ne voit pas le jour. Au lieu d'annoncer du vent, il faudrait annoncer des choses réel, de vrais projets opérationnel. C'est plus difficile de créer de vrai projet opérationnel. EuroNOG a été monté par 3 personnes en un week-end, on prépare deja le 1er meeting. Bref nous on a eu le courage de monter un NOG européen, personne ne l'a fait ou osé le faire. On est préparé à être démoli par des gens comme toi, c'est pour cela que Mike à fait l'annonce et pas moi. Inutile d'essayer de me troller dessus, Mike m'a beaucoup apprit, je ne referait pas les même erreurs comme dans le passé, c'est à dire de répondre aux messages trolls. En tout cas, je parie que tu viendra au premier meeting de EuroNOG, les gens comme toi critiquent, mais finallement ils profitent des choses discrètement. Inutile de balancer de la propagande, la propagende se retournera un jour contre toi. -- Nicolas DEFFAYET, NDSoftware NDSoftware NOC: http://noc.ndsoftwarenet.com/ FNIX6: http://www.fnix6.net/ EuroNOG: http://www.euronog.org/ Liste de diffusion du FRnOG http://www.frnog.org/ --- Archives : http://www.frnog.org/archives.php ---
Re: [FRnOG] BGP sur xDSL, quelqu'un ?
On Thu, 2002-12-05 at 10:30, Stephane Bortzmeyer wrote: Existe t-il en France un fournisseur qui fasse du BGP (la totale, avec les 110k routes) sur du xDSL (de préférence du bête ADSL de chez Netissimo) ? Sur du SDSL oui, sur du ADSL non. L'ADSL en France est relativement pourri, surtout au niveau latence comparé à d'autre pays. Traceroute à partir d'un lien ADSL au Luxembourg: 2 pppoe63-luxdsl-254.pt.lu (213.166.63.254) 23.001 ms 17.009 ms 17.410 ms 3 backbone2.pt.lu (194.154.192.152) 14.829 ms 13.661 ms 12.482 ms Traceroute à partir d'un lien ADSL en France: 3 loopback1-lns103-tip-telehouse.nerim.net (62.4.16.253) 60.300 ms 59.626 ms 74.469 ms 4 hsrp1-telehouse.nerim.net (62.4.16.9) 60.102 ms 56.700 ms 59.400 ms L'idée est qu'on dispose désormais avec Netissimo (ou dégroupage) d'un service raisonable pour faire une liaison de secours à très bon marché. Pour une boite qui a déjà un AS, son /24 et qui fait déjà du BGP avec son fournisseur principal, cela permettrait d'avoir un lien de secours en utilisant des technologies propres (pas de NAT ou autres horreurs). J'ai déjà contacté un fournisseur qui fait de l'ADSL et du BGP mais pas ensemble :-( Il y en a d'autres ? Il faut prendre un lien SDSL pour avoir du BGP. -- Nicolas DEFFAYET, NDSoftware NOC Website: http://noc.ndsoftwarenet.com/ FNIX6: http://www.fnix6.net/ Liste de diffusion du FRnOG http://www.frnog.org/ --- Archives : http://www.frnog.org/archives.php ---
Re: [FRnOG] Fournisseurs de transit IPv6 ?
On Fri, 2002-11-08 at 15:56, Stephane Bortzmeyer wrote: On Sun, Oct 06, 2002 at 02:32:32PM +0200, Stephane Bortzmeyer [EMAIL PROTECTED] wrote a message of 31 lines which said: BGP un préfixe à soi. Contactés, nos fournisseurs de transit IPv4 (Metromedia/Above.net et Telia) ont répondu par un écrasant silence, Il fallait juste augmenter le timeout : Telia a répondu et a proposé une offre très raisonnable et qui marche (via un tunnel chez eux, car tout leur réseau n'est pas encore IPv6). 2001:910:: est donc désormais routé. As-tu contacté un certain Mattias (la personne qui s'occupe de l'IPv6 chez Telia) dès le début ? Il y a un problème car j'ai plus ton sTLA dans mes tables de routage: route-server.ndsoftwarenet.net show ipv6 bgp 2001:910::/32 % Network not in table Par contre ton sTLA a été annoncé d'après: http://noc.ndsoftwarenet.com/stats/aspath-tree/history/35-FR-GITOYEN-20020924.php Nicolas DEFFAYET, NDSoftware NOC Website: http://noc.ndsoftwarenet.com/ FNIX6: http://www.fnix6.net/ Liste de diffusion du FRnOG http://www.frnog.org/ --- Archives : http://www.frnog.org/archives.php ---
