Re: [FRnOG] [MISC] Hébergeur Mail Perso : Bien choisir
Bonjour, Bonne année à tous ! Le 08/01/2024 à 09:09, Samuel Mesguich a écrit : Je suis en quête d'un hébergeur mail pour mes besoins "familiaux". J'envisage sérieusement Infomaniak J'ai quitté Gandi pour Infomaniak il y a quelques mois. Points positifs -> Stabilité: bien -> Support: bien -> Interface: bien Points négatifs -> Les redirections : il faut créer une boite pour chaque redirection, c'est un peu lourd (et facturé) -> L'antispam: gestion et fonctionnement à revoir En 2 mois, dans mon dossier spam, je n'ai eu aucun spam, mais uniquement des mails légitimes :-( Pire encore, avec la redirection, j'ai perdu des mails légitimes, car il est impossible de désactiver l'antispam sur les redirections. Le support est sympa et fait de son mieux, mais ne peut que signaler qu'un mail détecté est en fait légitime. Sur l'antispam et les redirections, Gandi était nettement plus performant. Bon courage. -- Emmanuel DECAEN --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Distance MINIMUM pour utilisation fibre monomode et sfp 10G
Bonjour, Tout dépend de la 10G utilisée, mais si tu es en 10G LR, pas de soucis, même sur une courte distance (2 M). Quelques liens: https://community.fs.com/fr/blog/optical-module-guide-10g-sfp-types-classification.html https://www.curvature.com/fr/resources/tech-guides/cisco-10gbe-optics-cheat-sheet/ Tu peux aussi le vérifier pratiquement en te connectant sur le management des deux switchs reliés en 10G LR. Tu fais afficher les caractéristiques du signal reçu sur chacun des switchs, puis tu vérifies qu'il se trouve entre le mini et le maxi. Bon courage. -- Emmanuel DECAEN Le 28/08/2023 à 09:58, Guillaume Roux a écrit : Bonjour Laurent, C'est un peu ce que dit mon expérience terrain, à part pour du DWDM je n'ai jamais eu à poser d'atténuateur nul part, même sur une jarretière mono entre switch et routeur de 3m, alors du coup je suis surpris quand deux anciens me sortent de façon très sur d'eux cette notion d'éblouissement causé par de la mono. D'une part ça contredit un certain nombre de use-case pourtant présent dans l'entreprise. D'autre part j'ai du mal à me dire que sur courte distance il y ait tant de dispersion/atténuation que ça sur de la multi pour que ce média soit dispensé de cette problématique. C'est pour ça que j'appelle à l'aide ici, dans l'espoir de trouver une publication/explication que je pourrais pousser en annexe pour étayer mes propos. Bonne journée, Guillaume --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Post-mortem Incident RENATER
Bonjour, Le 05/06/2023 à 09:50, Manuel BEGUIER a écrit : Effectivement, je me suis trompé sur le titre et d'autre part c'est effectivement ancien. Désolé pour ce post ... :( Même si c'est un peu ancien, cela reste intéressant :-) Le lun. 5 juin 2023 à 09:23, Manuel BEGUIER a écrit : le post-mortem de l'incident RENATER est détaillé chez Rémy Grünblatt : https://remy.grunblatt.org/renater-et-le-surblocage-un-cas-decole.html Cela rappelle aussi la difficulté à filtrer un site hébergé par une solution de ce type sans la participation du fournisseur (Cloudflare ou équivalent). Au final, pas mal de victimes collatérales... -- Emmanuel DECAEN --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] catalyst vs nexus dans DC spine / leaf
Bonjour, Le 31/05/2023 à 09:14, jehan procaccia INT a écrit : nous souhaitons passer sur une architecture spine/leaf dans notre (modeste, 20 baies) DC . nous connaissons bien par ailleurs (distributions prises batiments / acces) les catalyst 9500 en coeur et 9200/9300 en acces. Maintenant coté DC , tout le monde chez cisco ne semble jurer que par la gamme Nexus . N'est il pas possible de faire du spine en catalyst 9500 ou 9300, et des leaf en catalyst 9300 voire 9200 ? supportent t-ils l'achitecture spine/leaf - fabric IP / vxlan , bref on aimerai se debaraser de notre vieille archi core / access en spanning tree dans le DC. Merci pour vos conseils et/ou retour d'experience sur ces 2 grandes familles de switch en DC . Je ne vais pas pouvoir te répondre sur le choix Catalyst vs Nexus, car je n'ai jamais essayé ce type d'architecture sur Catalyst. Par contre, je peux te répondre en terme d'expérience :-) Ca fait plusieurs années, que j'ai du Nexus pour un nombre de baies similaire. Le passage en routage IP et VXLAN, s'est fait sans difficulté et sans coupure. Quelques avantages : - tous les liens sont redondants, la dernière grosse coupure d'un lien sur le réseau métro n'a même pas été perceptible (bascule inférieure à la seconde) - tous les liens sont actifs, plus aucun ne dort ou n'est en secours passif - avec un double attachement des serveurs de virtualisation, la perte ou la maintenance d'un switch est vraiment sans douleur - le mappage en BGP des MACs est très pratique pour la localisation et le diagnostic Il y a quelques points d'attention: Je pense qu'il faut s'assurer que l'équipe est formée sur le produit Nexus, et les technologies de l'architecture (routage, VXLAN, BGP, etc.) En outre l'automatisation de la configuration des VLANs et VXLANs pour l'exploitation quotidienne me parait indispensable pour éviter les gags. Bon courage. -- Emmanuel DECAEN --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [MISC] Question perso: fibre sans continuité
Bonjour, Le 23/11/2022 à 15:22, Oliver varenne a écrit : Mmm Appeler la commune ? Pas sur que ça marche... En l'occurrence en bout d'impasse, la commune à fait une découpe dans le goudron, et en a profité pour découper les fourreaux qui sont dessous... Puis, a recoulé du goudron dessus sans réparer. Depuis, c'est entre orange et eux, et visiblement ça ne bouge pas Donc en bout d'impasse, le pbo n'est plus relié. (et je devait être sur ce PBO à la base.) Si tu as une photo de la découpe des fourreaux (avant réparation), tu peux l'envoyer ici: https://dommages-reseaux.orange.fr/dist-dommages/app/signaler J'ai utilisé ce lien pour signaler un poteau en fâcheuse situation, voici le déroulé de la réparation: - déclaration : décembre - visite d'un sous-traitant : janvier - changement du poteau : mars Il y a un numéro de suivi, et tu es tenu informé. L'exemple donné par orange pour une coupure de câble enterré: https://dommages-reseaux.orange.fr/dist-dommages/assets/images/exemples/RS_CABLE.jpg Ca ne mange pas de pain d'essayer (sans impliquer la commune) :-) Dans mon cas de figure, je n'ai pas eu besoin d'expliquer la raison pour laquelle le poteau était dans cette situation. (des branches d'arbres non élagués s'appuient généreusement sur le câble téléphonique à chaque fois qu'il neige) Bon courage -- Emmanuel DECAEN --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Envoi de SMS en astreinte
Bonjour, Le 17/10/2022 à 09:07, Julien Issler a écrit : je me permet une petite incursion dans la discussion pour vous demander si pour ces usages de SMS d'astreinte vous utilisez des abonnements opérateurs/SIM spéciaux pour l'envoi des SMS, ou de simples lignes pro voir GP avec SMS illimités. Des abonnements spéciaux avec un support adapté. Merci. -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Envoi de SMS en astreinte
Bonjour Jérôme, Le 14/10/2022 à 15:45, Jerome SCHEVINGT a écrit : Le 14/10/2022 à 15:24, David Ponzone a écrit : Un Teltonika, ça fait envoi de SMS par API aussi, et ça se reboot à distance par SMS. Parce que je vous vois déployer des usines à gaz quand même non ? Tu as aussi des SMSEagle, vraiment de bon boitier, on en a 2 qui tourne dans deux datacenter differents avec des abo Orange/Sfr cela fonctionne très très bien. Envoi par API directement depuis Centreon, Observium et notre outils interne Faut pas chercher a faire compliqué c'est sur ;=) Effectivement, sur le papier, c'est pas mal, et pas très cher pour 8 modems: https://smseagle.eu/store/en/devices/40-45-smseagle-mhd-8100-4g.html Est-ce que l'on peut se connecter en admin sur l'OS (Ubuntu) ou est-ce uniquement via services (API, etc) ? Est-ce que l'on a accès à un journal d'envoi et de réception SMS (id sms, opérateur, couverture réseau,etc ) ? Merci. -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Envoi de SMS en astreinte
Bonjour, Le 14/10/2022 à 15:24, David Ponzone a écrit : Pour ce problème, on a quasiment (*) dédié du vieux Dell PowerEdge 2950 à l'usage SMS, on connecte les clefs sur des cartes USB PCIe. Et quand on a un problème avec un des modems, on éteint le serveur, puis on le rallume via l'iDrac. (*) Le serveur gère l'envoi des SMS (via API), les accusés de réception et les modems 3G. Un Teltonika, ça fait envoi de SMS par API aussi, et ça se reboot à distance par SMS. Parce que je vous vois déployer des usines à gaz quand même non ? En fait, c'est maitrisé côté serveur (environnement connu), et cela permet d'avoir la fiabilité et les capacités d'un serveur : redondance, journaux, diagnostic sur mesure, etc. Pourrais-tu me donner un exemple de modèle de teltonika pour l'envoi/réception de SMS ? Merci. -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Envoi de SMS en astreinte
Le 14/10/2022 à 15:30, Wallace a écrit : Ouah en ces temps de fin d'abondance c'est un peu overkill non niveau consommation élec? Effectivement, ça fait environ 20W par modem (conso serveur divisée par nb de modems), mais si je peux baisser cette consommation en gardant la fiabilité actuelle (serveur, double alim, etc) , ce sera tout bénéfice. On est sur des mini pc fanless avec celeron (on a arrêté les Rpi vu que plus dispo). On met ça sur différents sites mais pas aux DC car on capte toujours mal dans les DC et si on capte les répéteurs sont moisis quand ils sont pas illégaux... Sur ce coup, on a de la chance sur les différents DC, nous n'avons pas ce problème de couverture. Bon Week-End. -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Envoi de SMS en astreinte
Le 14/10/2022 à 14:28, Wallace a écrit : Le 14/10/2022 à 11:18, Emmanuel DECAEN a écrit : Finalement, lorsqu'une astreinte ne reçoit pas son SMS, il y a essentiellement deux raisons: - soit il n'est pas parti (ex: modem 3G en rade) et nous sommes au courant par l'erreur d'envoi Là la redondance peut faire des choses bien. :-) Quel marque/modèle de modem SMS utilisez-vous ? On un dongle usb Huawei 4G (je retrouve pas le modèle avec lsusb) mais on va arrêter avec cette marque car on s'arrache les cheveux à chaque nouveau modèle ou sous révision pour les faire basculer dans le mode usb qui va bien. Par défaut ça boot en mode iso9600 pour avoir un beau disque iso contenant les drivers et applications. Oui, c'est pareil pour le E173, c'est un peu lourd. Pour régler le problème, on a utilise ça : echo '12d1 1c05' > /sys/bus/usb-serial/drivers/option1/new_id Le deuxième boitier on l'a passé avec un modem 4G de Sierra Wireless pour avoir de belles antennes extérieures pour le meilleur signal possible et on communique par serial usb pour lui envoyer les textos, ça juste marche. Y a aussi une API mais on a pas joué avec. Le seuls défaut dans les deux solutions c'est que parfois (1 fois par an) ça décroche du signal et on sait pas les faire repartir à distance, les dongles usb si on redémarre l'ordi ça repasse en mode CD alors qu'il faudrait débrancher le dongle et attendre que le système boot pour faire le usbswitchmode. On a pas réussi à couper l'alimentation de l'usb hub à priori il faut une spécificité dans la carte mère qu'on a pas. Pour ce problème, on a quasiment (*) dédié du vieux Dell PowerEdge 2950 à l'usage SMS, on connecte les clefs sur des cartes USB PCIe. Et quand on a un problème avec un des modems, on éteint le serveur, puis on le rallume via l'iDrac. (*) Le serveur gère l'envoi des SMS (via API), les accusés de réception et les modems 3G. Et pour le Sierra wireless soit il est encore joignable et on peut lui demander un reboot soit il ne répond pas et il faudrait mettre une prise connectée qu'on a pas fait. C'est noté pour Sierra Wireless, je l'ajoute aux marques citées par Paul : Wavecom/ErcoGener Mais bon comme on reboot après chaque maj kernel nos serveurs y compris bare metal, on applique la petite procédure de débranchement du dongle usb pour le huawei jusqu'à ce qu'on le remplace par un autre sierra wireless. En tout cas cette solution on la préfère car on a la main complète sur les textos et la redondance jusqu'à l'envoi par gsm. Alors que dans les services SaaS on est pas au courant des problèmes et on n'est pas notifié en temps et en heure. C'est plutôt pour des usages marketing ces services là, ce n'est pas fait pour de l'astreinte. Merci. -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Envoi de SMS en astreinte
Bonjour, Le 13/10/2022 à 22:30, Wallace a écrit : Nous c'est le chemin inverse qu'on a fait. On a testé différents prestataires SMS par API (je les nommerais pas mais tous FR et un DE) et on a eu parfois des délais trop long jusqu'à plusieurs heures pour recevoir les textos. C'est assez facile de voir que c'est eux qui ont un souci puisqu'en plus de la personne d'astreinte, d'autres personnes sont également destinataire mais mettent en sourdine la nuit. Quand on regarde sur l'ensemble des téléphones et que les 4 opérateurs reçoivent bien tous le texto horodaté plusieurs heures après le call API, on en conclue assez rapidement que c'est pas le réseau opérateur du destinataire mais le réseau source. C'est ce qui me gêne le plus. Du coup on a préféré doublé le modem 3G et carte sim sur un deuxième opérateur et mettre le tout sur un autre site pour avoir une redondance totale. On fait les requêtes en round robin dns avec une détection de la disponibilité des points d'entrés qui va modifier le fqdn pour désactiver l'ip qui serait down. C'est effectivement notre solution actuelle: - l'accusé de réception est vraiment très utile - le délai de transmission est très rapide (on le constate avec les accusés de réception) Finalement, lorsqu'une astreinte ne reçoit pas son SMS, il y a essentiellement deux raisons: - soit il n'est pas parti (ex: modem 3G en rade) et nous sommes au courant par l'erreur d'envoi - soit l'opérateur mobile du destinataire a un problème et nous sommes au courant car nous n'avons pas l'accusé de réception De notre côté, on utilise des E173 pour l'envoi, mais ils sont vieillissants, et je vais devoir les renouveler. Quel marque/modèle de modem SMS utilisez-vous ? En êtes-vous content ? Merci. -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [BIZ] Envoi de SMS en astreinte
Bonjour, A l'heure actuelle, nous envoyons des notifications SMS pour les astreintes, pour cela nous utilisons deux solutions : - envoi de SMS via modem 3G + SIM spécifique à cet usage - envoi par API chez un prestataire Chacune avec des avantages / inconvénients: - simplicité de gestion - fiabilité/rapidité d'envoi du SMS. - disponibilité "Internet" du site - facilité du diagnostic en cas de soucis en 24/7 (support et log) - accusé de réception fiable ... Je cherche a faire évoluer cette solution en restant sur du SMS (pas besoin de 3G/4G/5G pour le destinataire). Je vais conserver la solution modem 3G + SIM en secours, mais faire monter en puissance la solution via API. Quels prestataires utilisez-vous pour vos SMS d'astreinte (si vous le faites par SMS) ? Avez-vous une préconisation de prestataire fiable d'envoi SMS via API (idéalement avec support 24/7) ? (nous avons une faible consommation d'environ 10 000 SMS / mois) Je vous remercie. -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Module SFP+ mikrotik - HPE
Bonjour, Le 09/09/2022 à 04:32, Olivier Lange a écrit : Je les ai contactés, pour avoir un retour, mais je me disais que peut être certains avaient déjà fait ce genre de tests, et pouvaient directement me conseiller de l'équipement qui fonctionne :p. Le DAC serait clairement une bonne solution, mais justement, je cherche ce genre de retour... Sur mes derniers achats, j'ai pris du FS Twinax 10G (et pour certains "compatible" Cisco), et visiblement côté HPE pas de soucis particulier. Sur un serveur HPE Apollo 4200 récent: ethtool -m ens1f1 Identifier : 0x03 (SFP) Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID) Connector : 0x21 (Copper pigtail) Transceiver type : Passive Cable Passive Cu cmplnce. : 0x01 (SFF-8431 appendix E) [SFF-8472 rev10.4 only] Vendor name : FS Vendor OUI : 41:50:48 Vendor PN : SFPP-PC02 Vendor rev : C Date code : 200602 Et côté switch Cisco: show interface Eth1/19 transceiver Ethernet1/19 transceiver is present type is SFP-H10GB-CU2M name is FS part number is SFPP-PC02 revision is C Link length supported for copper is 2 m cisco id is 3 cisco extended id number is 4 Etant donné le prix d'un câble, ça vaut le coup de tester ;-) Bon courage. -- Emmanuel DECAEN --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] fin du support de ssh-rsa signé avec sha-1
Bonsoir, Le 29/08/2022 à 18:51, Pierre Colombier via frnog a écrit : [...] J'entends bien que le *format* "ssh-rsa" n'est pas déprécié. D'ailleurs ma nouvelle clé publique type "rsa-sha2-256" commence bien par "ssh-rsa B3NzaC1yc2EAA.." Ma question "académique" est que je ne comprends pas d'où vient ce besoin d'une signature/hash ? que ce soit md5, sha1, sha256 ou autre, en quoi l'algo rsa seul n'est-il pas suffisant ? Une petite explication sympa: https://levelup.gitconnected.com/demystifying-ssh-rsa-in-openssh-deprecation-notice-22feb1b52acd Bonne lecture. -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Curieux spam post-FRnog
Bonjour Stéphane, Le 28/03/2022 à 15:11, Stephane Bortzmeyer a écrit : Le 14 décembre dernier, j'envoie un message sur la liste FRnog. Et, là, je reçois un spam de hameçonnage avec un sujet qui est le Re: du message en question, une partie du message dans le corps mais pas de Reply-To:. Quelqu'un se sert des archives de FRnog pour générer du spam ? Dans le but d'augmenter les chances de passer à travers les anti-spams ? Je ne sais pas si c'est le même cas, que ce que je peux constater: -> mail émis depuis une IP 62.3.58.0/24 -> envoi massif ce lundi entre 12H et 14H -> avec clamscan, on obtient: Doc.Downloader.Qbot03222-9942295-0 FOUND Cela ressemble à un piratage de boite chez pas mal de monde. Merci. -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Logiciel d'inventaire orienté objet
Bonsoir, Le 19/01/2022 à 22:39, Pierre Sarret via frnog a écrit : Je ne pense pas que ça puisse répondre à 100% au besoin, mais Netbox permet de faire pas mal de tweaks avec les champs customs, mais est plus orienté IPAM que inventaire client pour le coup Mais ça peut répondre à une bonne partie du besoin en tout cas sur la partie recherche j'en suis certain ! :) Pour l'utiliser quotidiennement, je n'ai pas eu de soucis pour le moment sur une limitation au niveau de notre inventaire matériel. Oui, netbox est vraiment très bien. Le seul petit truc que je trouve pénible, c'est la partie simplex vs duplex pour les connexions fibres. Si tu as un tiroir 12 FO, tu peux le représenter avec un modèle 12 simplex ou un modèle 6 duplex, ça c'est plutôt simple. Mais si tu te retrouves avec un mix du genre 2 simplex et 5 duplex sur ton tiroir 12FO, c'est un tantinet plus délicat à saisir. Dans les trucs sympas, le suivi de bout en bout des connexions et des liaisons, est vraiment un énorme +. Quand tu ouvres ton switch, tu vois le raccordement direct de chaque port (tiroir optique), mais aussi l'autre extrémité avec le switch distant et son port. On a pas mal de DWDM entre nos datacenters, et la trace suit parfaitement de bout en bout : ports, prises, mtp, trunk, mux, longueurs d'onde, etc. Il faut uniquement saisir les tronçons, et netbox fait le reste. Exemple: switch 3 datacenter A / xg47 <-> optique 1&2 <-> DWDM C36 <-> optique 4&5 <-> switch 7 datacenter B / xg48 Merci. -- *Emmanuel DECAEN * --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Prix des déports MMR -> baie client en DC
Bonsoir, Le 19/01/2022 à 18:15, Laurent CARON a écrit : Je n'avais pas commandé de déport depuis plusieurs années en DC. Je m'aperçois que le coût des déports est devenu exhorbitant (~500€/HT de FAS et ~90€/HT/mois de maintenance). Est-ce pareil dans tous les DC ? C'est très variable selon le DC: -> pour les frais d'accès au service, c'est en général plusieurs centaines d'Euros. -> pour le mensuel, l'écart est plus important : cela va de 0 € à plusieurs centaines d'Euros par mois. Arrivez-vous à négocier ces frais ? Avec du chiffre d'affaire à la clef, ce doit être envisageable... Le choix est assez vaste côté DC en France, si le prix est trop élevé en comparaison du service, il ne faut pas hésiter à faire raisonnablement jouer la concurrence. Merci. -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Solution pour réception xG
Bonjour, Le 16/09/2021 à 10:10, Daniel via frnog a écrit : un client a une mauvaise réception xG dans ses locaux (hangar métallique) et passe son temps à l'extérieur pour répondre à ses appels. Quelle-s solution-s existe-nt afin de résoudre ce problème ? Au cas ou: iPhone + opérateur Free, lien FTTH Free mini 4k A moins que la femtocell 3G de la mini 4K ne couvre tout le hangar, la solution peut-être d'utiliser les appels sur Wifi. Par exemple chez Orange: https://reseaux.orange.fr/famille/appels-wifi Ca nécessite de migrer chez un opérateur qui supporte les appels Wifi, et d'avoir une installation Wifi correcte dans le hangar. Bon courage. -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] OSPF cost et référence
Bonjour, Aujourd'hui, bien que sa référence de bande passante soit à 100 Mbps, le calcul de cout OSPF (et donc sa référence) dépend beaucoup des implémentations des éditeurs/constructeurs de routeurs. Dans FRR en v8, bien que la documentation indique 100 Mbps, la référence par défaut (no auto-cost) semble être 100 Gbps. # show ip ospf interface ens21 is up ifindex 5, MTU 1500 bytes, BW 1 Mbit Router ID a.b.c.d, Network Type BROADCAST, Cost: 10 100G / 10G => cost 10 Sur les Nexus Cisco, la référence par défaut est à 40 Gbps (conforme à la doc). # show ip ospf interface Ethernet1/48 is up, line protocol is up Unnumbered interface using IP address of loopback0 State P2P, Network type P2P, cost 4 40G / 10G => cost 4 Évidemment, c'est assez incohérent d'avoir deux couts différents pour une interface de même débit ;-) Je vais donc choisir une référence commune, et je pensais prendre une référence 1Tbps: auto-cost reference-bandwidth 1000 Gbps 1G -> 1000 10G -> 100 100G -> 10 Qu'en pensez-vous ? Qu'avez-vous choisi dans votre environnement (informatique interne, datacenter, VM) ? Merci. -- Emmanuel DECAEN --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] [BGP] [Cisco]
Bonjour, Le 22/07/2021 à 11:40, Jérôme BERTHIER a écrit : Le 14/07/2021 à 22:18, Emmanuel DECAEN a écrit : Dans ce cas, la distinction entre les deux liens ne se fait plus par l'IP, mais par l'interface utilisée sur l'équipement (Router Interface Address). L'avantage, et pas des moindres, c'est que tu ajoutes autant d'interconnexions que tu veux, sans avoir à te poser de question d'adressage, il faut juste monter ton interface de routage (sans adresse IP) de chaque côté (et c'est tout). Question peut être bête mais comment gères-tu la détection rapide de dysfonctionnement d'un lien sans perte d'état de l'interface elle même ? Je n'ai pas encore eu le cas de figure d'un lien qui tombe sans perte d'état de l'interface. Tous les liens entre les équipements sont directs (i.e. sans matériel actif entre le deux), cela doit certainement contribuer à faciliter la détection d'un lien qui tombe. A priori, BFD ça ne marche pas avec l'IP unumbered sur Nexus : https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/7-x/interfaces/configuration/guide/b_Cisco_Nexus_9000_Series_NX-OS_Interfaces_Configuration_Guide_7x/b_Cisco_Nexus_9000_Series_NX-OS_Interfaces_Configuration_Guide_7x_chapter_0110.html#concept_FBA5494FBDAA4D599394E61823E16C07 Il reste que le tuning OSPF ? Parce que sinon y a un bon risque que l'ECMP te fasse passer par le lien coupé le temps du dead timer , non ? Oui, c'est le risque. Ceci étant, je relativise un peu, car les liaisons et les équipements réseaux sont très fiables. En 15 ans, les pannes se comptent sur les doigts d'une main, avec un impact souvent négligeable. Et honnêtement, avec un dead timer à 40 secondes, si un jour il doit y avoir une coupure d'un lien sans perte d'état, on fera avec ;-) -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] [BGP] [Cisco]
Le 14/07/2021 à 12:27, David Ponzone a écrit : Intercos L3 ? Oui, des intercos L3 , avec du VXLAN sur chaque switch. OSPF marche sur du unnumbered ou tu dois utiliser ISIS ou EIGRP ? Oui, c'est de l'OSPF. Le unnumbered est agréable en OSPF, voici un exemple de traceroute où l'on voit les loopbacks: # traceroute 10.0.0.4 traceroute to 10.0.0.4, 30 hops max, 40 byte packets 1 10.0.0.2 1.033 ms 0.933 ms 0.804 ms 2 10.0.0.3 0.669 ms 0.63 ms 0.546 ms 3 10.0.0.4 0.892 ms 0.842 ms 0.66 ms Ces switchs sont situés sur un boucle optique de quelques dizaines de KM. Et comme "un switch = une IP", c'est très simple de diagnostiquer (pas besoin de chercher où se trouve le subnet). Cerise sur le gâteau, tu peux parfaitement avoir plusieurs liens "unnumbered" entre deux switchs, le .2 et le .3 dans l'exemple ci-dessous: # show ip ospf database detail LS Type: Router Links Link State ID: 10.0.0.2 Advertising Router: 10.0.0.2 Link connected to: a Router (point-to-point) (Link ID) Neighboring Router ID: 10.0.0.3 (Link Data) Router Interface address: 0.0.0.5 Link connected to: a Router (point-to-point) (Link ID) Neighboring Router ID: 10.0.0.3 (Link Data) Router Interface address: 0.0.0.6 Dans ce cas, la distinction entre les deux liens ne se fait plus par l'IP, mais par l'interface utilisée sur l'équipement (Router Interface Address). L'avantage, et pas des moindres, c'est que tu ajoutes autant d'interconnexions que tu veux, sans avoir à te poser de question d'adressage, il faut juste monter ton interface de routage (sans adresse IP) de chaque côté (et c'est tout). Et bien sûr, rajouter un switch se limite à mettre une loopback unique ;-) -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] [BGP] [Cisco]
Bonjour, Le 13/07/2021 à 05:05, Michel Py via frnog a écrit : Michel Py a écrit : Ceci étant dit, pour moi CIDR c'est simple : le masque peut être à n'importe quel bit. C'est classful qui est restreint. Erwan David a écrit : Y compris le /31 (et oui il y a encore des équipements qui ne le supportent pas) Dans le temps il y avait aussi "ip unnumbered". Ca n'a pas eu le succès populaire escompté, non plus; pour tant, au lieu de gaspiller 4 adresses, ou même deux pour un /31, ça en gaspillait zéro. Le "ip unnumbered" me plait bien. On l'utilise sur les interconnexions de tous nos switchs Cisco Nexus, et ça simplifie pas mal de choses, en particulier sur les déploiements et le dépannage. -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] T2 sur réseau FO opérateur SFR - blocage numéro masqué sur harcèlement
Bonsoir, Le 10/07/2021 à 06:58, Ville numérique a écrit : Il y a décision de justice : Daniel MALGUY a écrit : quelqu'un ici sait il (ou elle) s'il est possible de demander à un >opérateur (groupement de T2 SFR) de bloquer un numéro masqué, >suite à décision de justice ? mais SFR nous dit "pas possible de bloquer au niveau opérateur" Et la personne ne cherche pas apparemment à changer de numéro. Elle le ferait si nous obtenions de Free (par la justice) que Free résilie sont numéro. Donc je cherche à savoir si SFR peut ou non bloquer (auquel cas nos juristes tenterons de l'obliger). Si ce n'est pas possible nous éviterons de nous ridiculiser en insistant auprès de SFR. Et nous opterons pour rejeter poliment les appels masqués, mais ce serait gêner des usagers qui n'ont rien à voir dans l'affaire et qui n'apprécieraient pas le rejet, même poli ! Si le numéro est masqué, plutôt que de le rejeter (même poliment), il y a toujours la solution de demander à l'appelant de taper son numéro de téléphone afin qu'il soit rappelé. Un scénario du genre: Accueil vocal: "Mairie de , bonjour ! Afin d'être rappelé par un de nos téléconseillers, tapez sur #" Deux cas se présentent, soit: - l'appelant ne tape pas "#" => message: "vous pouvez laisser un message" puis renvoyer l'appel vers la MEVO - l'appelant tape "#" => message: "tapez maintenant les 10 chiffres de votre numéro téléphone" puis après vérification, rappeler automatiquement le numéro tapé Ce n'est pas parfait, et il reste un risque que le numéro tapé soit incorrect, mais au moins, il n'y a plus de harcèlement, et l'appelant légitime n'est pas envoyé sur les roses. Bon courage. -- Emmanuel DECAEN --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] choix transitaires
Bonjour, Le 11/06/2021 à 06:06, Romain BAFFERT a écrit : Indépendamment de leurs politiques commerciales (ça semble être les soldes en fin de trimestre, on me baisse le prix chaque semaine pour que je commande ;) ) quels sont vos retours d’expérience sur les différents « gros » que sont lumen / gtt / telia ? Y’a t’il de vraies différences techniques / support / pratiques / relationnelles qui excluent certains ? J’ai déjà exclu (a tord ou à raison ?) cogent par les retours que j’en ai eu + le fait qu’ils n’ont pas tout internet ipv6 et que ça sent mauvais de partie avec une rustine… Je ne suis pas certain qu'il faille l'exclure. Cogent a un avantage énorme sur la partie transit, il a un support compétent et réactif en 24/7. En gros ils me pondent tous des prix assez similaires et en pleine dégringolade pour du giga de commit sur 10 giga. Si certains petits / débutants ici ont des conseils suivant leur expérience je suis preneur…. J’hésite notamment à leur demander l’option d’un lien double sur mes deux dc. Je me dis que le surcoût est peut être négligeable et ça peut aider beaucoup en cas de souci… D’un point de vue contrat, vu que les prix dégringolent chaque année, que négociez vous quand vous entrez chez un fournisseur ? Réévaluation des prix sur la durée de l’engagement ? Croissance du débit à prix constant etc ? En gros j’ai l’impression que m’engager sur 3 ans sur un fournisseur même avec une belle remise sera au final plus douteux que de les challenger chaque année :) ça c’était pour la partie commerciale. De mon côté, je suis plutôt sur de l'engagement d'un an, mais ceux qui travaillent avec moi, savent que je suis plutôt fidèle si les conditions restent correctes. Donc au final, je suis toujours avec certains fournisseurs de transit depuis plus de 15 ans ;-) Et cette fidélité, ne m'a jamais empêché de dire ce que je pense quand ça ne va pas techniquement ou commercialement. Pour la partie plus technique : j’ai vu récemment le sujet avec le bordel qu’était bgp. En soi ça ne me fait pas peur (j’aurais jamais monté ma boîte y’a 10 ans si j’avais peur :D) mais est-ce que justement certains tier1 gèrent mieux / plus de souplesse / meilleur support force de conseils sur la partie bgp Des gens comme France-IX Lyon peuvent t'apporter pas mal sur ce sujet. Il ne faut pas hésiter à prendre leur formation BGP et former toute ton équipe... Pour ce qui est du ddos est-ce que certains ici traitent ça a l’extérieur (type nawas / neustar / corero) ? J’essaye d’avoir une bonne protection sans pour autant me faire exploser d’entrée de jeu au niveau coûts alors que je ne fais que commencer cette activité (mais je veux la débuter propre)… l’achat ou la prise en leasing de boîtiers me semble pas adaptée au besoin. Pour le DDoS, il me parait important d'envisager les deux possibilités: -> ceux qui ne font que ça, avec qui tu apprends souvent beaucoup de chose -> ceux qui le vendent en option sur le transit à un prix globalement raisonnable Et pour finir, je me pose la question de l’opportunité de compléter tout de suite / plus tard / pas du tout par une présence avec un IX type lyonIX (je suis sur lyon)… Au plaisir d’échanger avec la communauté / échange de bons procédés :) Pour moi, ce qu'apporte LyonIX (ou GrenoblIX dans mon cas), c'est : -> une communauté locale qui te permet d'échanger facilement avec tes confrères du coin (soirée, formation, etc.) -> un interlocuteur disponible avec une vision très étendue du marché hébergeur/opérateur et des opportunités Bref, pour se lancer, cela n'a pas de prix ;-) Au plaisir de prendre un bière ou un café si tu passes sur Grenoble. -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] [BGP] Traffic arrivant sur un seul lien au lieu de deux
Le 10/06/2021 à 01:15, Michel Py via frnog a écrit : Comment expliquer que dans certains looking-glass (pas tous), on ne voit même pas ce chemin ? Peut-être sur la vérification de la route et de l'AS. L'AS 34536 n'a pas d'objet route pour 80.77.225.0/24 $ whois -T route 80.77.225.0/24 route: 80.77.225.0/24 origin: AS12670 mnt-by: AS12670-MNT $ whois -T route 80.77.224.0/24 route: 80.77.224.0/20 origin: AS12670 mnt-by: AS12670-MNT mnt-routes: NEWEL-MNT route: 80.77.224.0/20 origin: AS34536 mnt-by: NEWEL-MNT Bonne journée. -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH][BGP] Traffic arrivant sur un seul lien au lieu de deux
Bonsoir, Le 09/06/2021 à 18:09, Mathieu KERN via frnog a écrit : J'ai un problème avec notre AS34536 que j'ai du mal a comprendre, nous avons deux liens, avec cogent et SFR, et annonçons nos préfixes 80.77.225.0/24 et 80.77.224.0/24 des deux cotés, en utilisant l'AS prepending pour ne faire rentrer que l'un des prefixes pour chaque lien quand ils sont fonctionnels. Le 224 passe par SFR ( AS1557) et le 225 devrais passer par cogent, mais ce n'est pas le cas depuis plusieurs jours, alors que la configuration n'a pas changé depuis des semaines. Hors en regardant plusieurs looking glass je ne vois pas de problème d'annonces. J'ai même demandé a cogent, qui me confirme que eux même reçoivent bien nos annonces BGP avec les bons chemins. Voici un résumé de ce que je vois de mon côté: $ show ip bgp 80.77.224.0/24 BGP routing table entry for 80.77.224.0/24 Paths: (3 available, best #1, table default) 15557 34536 Origin IGP, localpref 130, valid, internal, best (Local Pref) Community: 0:5410 0:15169 0:15557 0:21502 0:24940 0:57859 43100:1010 43100:9992 43100:65002 174 15557 34536 Origin IGP, metric 37091, valid, external Community: 174:21101 174:22008 3215 15557 34536 Origin IGP, valid, external $ show ip bgp 80.77.225.0/24 BGP routing table entry for 80.77.225.0/24 Paths: (3 available, best #1, table default) 15557 34536 34536 34536 34536 34536 34536 Origin IGP, localpref 130, valid, internal, best (Local Pref) Community: 0:5410 0:15169 0:15557 0:21502 0:24940 0:57859 43100:1010 43100:9992 43100:65002 174 34536 Origin IGP, metric 43130, valid, external Community: 174:21101 174:22008 3215 15557 34536 34536 34536 34536 34536 34536 Origin IGP, valid, external Dans mon cas, les deux chemins passent par SFR (15557) pour une raison très simple: Je privilégie le trafic de France-IX Grenoble (local pref 130). Et comme SFR est présent sur France-IX, alors que Cogent en est absent, le chemin via SFR se trouve privilégié. Bon courage. -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] carte FS 25GbEpour serveur hpe?
Bonjour, Le 08/06/2021 à 16:05, Michel Py via frnog a écrit : Benoit Chesneau a écrit : Quelqu’un a testé les cartes 25Gbe de chez FS pour les serveurs HP. Je réfléchis a utiliser ces cartes pour brancher 3 DL160 Gen10 en mesh pour un petit cluster proxmox avec ceph. Les cartes officielles marquées HPE sont un peu chère… Je me demande comment ces cartes réagissent et si ils interfèrent avec le refroidissement. (iesi leurs capteurs sont bien pris en compte par iLO. Ou peut-être utiliser d’autres cartes/ fournisseur? On a eu des galères avec les cartes à chipset Mellanox et VMWare. Rien à voir avec fs.com (elles ne venaient pas de là) et pourtant Mellanox j'aimais bien, mais depuis quelques temps on ne prend plus que les cartes à chipset Intel. Jamais essayé ce modèle particulier, mais les 10G ça juste marche : https://www.fs.com/products/75603.html Attention à certains modèles Intel 10G avec Proxmox, sur de l'Intel X710 10G, j'ai eu ce problème: https://forum.proxmox.com/threads/error-i40e_aq_rc_enospc-forcing-overflow-promiscuous-on-pf.62875/ => Pas de soucis avec de l'Intel X520 pour le moment. Concernant HPE, il ne faut pas hésiter à demander à un devis à son grossiste. Dans une config HPE récente, le prix de la carte 10G HPE était à un prix très intéressant par rapport à FS. Est-ce qu'il y a des modèles des cartes HPE 40 Gbps à éviter avec Proxmox ? Merci. -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?
Bonsoir, Le 21/05/2021 à 18:48, aderum...@odiso.com a écrit : Le vendredi 21 mai 2021 à 14:02 +0200, Emmanuel DECAEN a écrit : Sur le principe oui, c'est sympa, mais à moins de changer toute l'infrastructure, la suppression de l'ARP peut poser problème si elle se fait par étape, en commençant par le coeur. Cas concret: Infrastructure avec deux switchs clients A et B (L2) connectés sur deux switchs de coeur "datacenter" (VXLAN + suppress ARP + BGP-EVPN) Ton client décide de basculer son serveur entre ses deux switchs (A->B) => le serveur devient injoignable. Dans un réseau uniquement L2, à la première requête ARP, la réponse du serveur permet de mettre à jour la table d'adresse MAC sur le chemin de switchs (y compris le coeur). Dans un réseau mixte L2 + VXLAN (avec suppress-arp), le requête ARP sera filtrée (suppress-arp) et n'arrivera jamais au serveur, le serveur ne sera plus joignable. Il y a plusieurs solutions de contournement : timeout arp, retrait du suppress-arp Si quelqu'un a une meilleure solution, je suis preneur. Mais en attendant, à diagnostiquer la première fois, c'est un peu coton ;-) Je pense que le problème, c'est que tu ne fais pas de l'evpn de bout en bout, mais uniquement sur tes coeurs. Oui, nous sommes d'accord, c'est bien le problème avec le suppress-arp dans ce contexte. Et je ne me vois pas balancer tout le parc de switchs L2 d'extrémité parce qu'ils ne savent pas faire du VXLAN. => Le compromis du retrait du suppress-arp est acceptable en attendant le renouvèlement du parc :-) Bon Week-End -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?
Le 21/05/2021 à 12:42, Benjamin CALLAR a écrit : Idem sur la gestion des tables CAM, où celle-ci peuvent être gérer de manière centralisée, et éviter l'auto-apprentissage de celles-ci, et pourquoi pas faire du switching intelligent (load balancing, ...) comme le permet à peu prêt le PBR que nous connaissons tous, mais au niveau 2.=> Adieu le spanning-tree Oui, c'est un gros gain de supprimer le spanning-tree, on utilise tous les liens en même temps, et la bascule en cas de panne se fait en moins d'une seconde. Pour éviter le risque de SPOF avec la centralisation, on a "stocké" les MAC + IP/MAC sur deux route-reflector. Pour revenir à la partie configuration centralisée, pour moi, cela reste le point délicat. Sur le papier c'est sympa, mais dans la réalité les modules ansible évoluent parfois avec des modifications critiques, il faut être attentif et prudent. Par exemple la disparition du "switchport mode" dans une évolution : https://github.com/ansible/ansible/issues/65032 Je pense que la centralisation de la configuration est indispensable pour un réseau significatif en constante évolution, ça simplifie les configurations et limite les erreurs, mais il faut être très rigoureux dans le suivi du produit. Si le produit est opensource (comme ansible), cela signifie passer du temps à suivre ses évolutions et bugs. Si le produit est propriétaire, il faut non seulement suivre le produit, mais aussi l'évolution de l'éditeur (santé, rachats, etc.) pour s'assurer de la pérennité du produit. -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] SDN (Software Defined Networking): Bullshit ou réalité ?
Bonjour, Le 21/05/2021 à 12:42, Benjamin CALLAR a écrit : Pour argumenter le débat, le SDN a tout a fait sa place dans un environnement complexe style Datacenter, et comme j'ai pu le voir plus tôt aussi, en séparant le controlplane du dataplane. Imaginez un monde ou le broadcast ARP disparait, ce serait top non ? (ne me parlez pas d'IPv6 ...) Clairement, le SDN peut répondre à cela, le contrôleur ayant une connaissance globale du réseau, la requête peut être répondu localement par le premier saut sans avoir à traverser le réseau ! Sur le principe oui, c'est sympa, mais à moins de changer toute l'infrastructure, la suppression de l'ARP peut poser problème si elle se fait par étape, en commençant par le coeur. Cas concret: Infrastructure avec deux switchs clients A et B (L2) connectés sur deux switchs de coeur "datacenter" (VXLAN + suppress ARP + BGP-EVPN) Ton client décide de basculer son serveur entre ses deux switchs (A->B) => le serveur devient injoignable. Dans un réseau uniquement L2, à la première requête ARP, la réponse du serveur permet de mettre à jour la table d'adresse MAC sur le chemin de switchs (y compris le coeur). Dans un réseau mixte L2 + VXLAN (avec suppress-arp), le requête ARP sera filtrée (suppress-arp) et n'arrivera jamais au serveur, le serveur ne sera plus joignable. Il y a plusieurs solutions de contournement : timeout arp, retrait du suppress-arp Si quelqu'un a une meilleure solution, je suis preneur. Mais en attendant, à diagnostiquer la première fois, c'est un peu coton ;-) -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Panne SIP Free résolue pour Gigaset N720
Bonjour, Le 28/04/2021 à 18:03, Gérald Vannier a écrit : Pb semble référencé chez Free (la date correspond). https://dev.freebox.fr/bugs/task/34622 FS#34622 : PB Softphone Pro depuis 4.3.0 Merci pour l'information, j'ai signalé que le problème concernait également les bornes Gigaset N720. Maxime Bizon (Freebox) a fait un correctif temporaire hier soir afin que cela fonctionne de nouveau avec la Freebox (firmware en beta). Merci. -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Panne SIP Free (Free et Centile)
Le 22/04/2021 à 11:18, Raphael Mazelier a écrit : Le SIP over internet, over un truc qui fait du bricolage nat comme le cgnat free, bon courage en effet. C'est bien pour cela que les entreprises de Centrex fournissait l'accès internet ou exigeait un accès vraiment neutre (ou mettais en place un VPN). On ne peut pas forcer nos salariés (en télétravail) à changer de FAI, d'autant que certains sont un peu distant "physiquement", en Polynésie ;-) bref bon debug. Je me demande si les Freebox Pro sont aussi concernées. -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Free et Centile
Le 22/04/2021 à 11:36, Richard Klein a écrit : Juste une idée en l'aire, mais est-ce que les 1/4 d'adresses .Dans ce cas dans aller dans l'interface client free ( sur le web pas sur la box)et demander une adresse IP statique full stack Ce problème est présent sur des femtocell! Le problème est également présent en Full Stack. -- Emmanuel DECAEN --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Panne SIP Free (Free et Centile)
Bonjour, Oui, je constate aussi le problème, cela ne concerne pas que Centile, j'ai une borne Gigaset N720 touchée. Dans le cas de la borne Gigaset, l'audio ne fonctionne que dans un sens. Il faudrait voir si la nouvelle version des Freebox (4.3.x) n'est pas en cause. Bon courage. -- Emmanuel DECAEN Le 22/04/2021 à 10:31, Julien OHAYON a écrit : Bonjour à tous, Depuis hier fin d'après après midi et surtout depuis ce matin, de plus en plus d'utilisateurs ont du mal à connecter leur softphone. En regroupant le tout on remarque qu'à chaque fois les utilisateurs sont chez Free. Notre plateforme Centile n'est pour le moment qu'en IPv4 (oui je sais boh tu as qu'à mettre du v6) . Est-ce que d'autres ont détecté des problèmes depuis peu entre Free et des plateformes Centile ? Désolé pour le bruit Julien --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] OVH : SBG-2 en feu
Le 13/03/2021 à 08:47, Stéphane Rivière a écrit : Il y a plusieurs années, nous avons subit un emballement thermique sur un onduleur. Quelle puissance environ ? Un onduleur de 30 KVA. Lorsque le technicien est arrivé sur site, il a extrait toutes les batteries, et confirmer le diagnostic : emballement thermique suite à la défaillance d'une batterie. Voici une petite photo de l'état dans lequel se trouvaient les batteries: Si t'as un lien, pour "l'édification des masses", on est pour :) Dans le carton, on voit quelques batteries gonflées et d'autres sans dommage apparent: http://dl.free.fr/oaWpyYqQr http://dl.free.fr/kFoYYCSuf Cette différence est dû au lieu d'implantation dans l'onduleur. Au delà de l'apparence, pour le technicien intervenu sur site, toutes les batteries ont souffert et doivent être changées. -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] OVH : SBG-2 en feu
Bonsoir, Le 12/03/2021 à 09:55, Clement Cavadore a écrit : Le vendredi 12 mars 2021 à 09:45 +0100, Stéphane Rivière a écrit : Finalement, les GE (feu, explosion), les onduleurs (feu), les salles batteries (explosion) devraient être traités comme des dépôts de munitions, et placés dans des îlots à l'extérieur des DC... So true (je me suis fait la même réflexion, car les départ d'incendie côté onduleurs, c'est pas rare). Il y a plusieurs années, nous avons subit un emballement thermique sur un onduleur. La supervision (Nagios à l'époque) a commencé par détecter un augmentation de quelques degrés sur les batteries de l'onduleur. Pensant que la climatisation avait un problème, nous sommes allés voir... Mais rien, rien du tout: -> la climatisation fonctionnait très bien -> absolument aucun signe anormal côté onduleur, pas d'alerte sur l'écran -> aucun signe extérieur : aucune odeur, aucune fumée Inquiets de cette situation, l'astreinte a appelé le constructeur, et là, par téléphone, le technicien a tout de suite identifié le risque ! Ce dernier a fait couper immédiatement l'alimentation des batteries et fait passer en bypass. Lorsque le technicien est arrivé sur site, il a extrait toutes les batteries, et confirmer le diagnostic : emballement thermique suite à la défaillance d'une batterie. Voici une petite photo de l'état dans lequel se trouvaient les batteries: Ce que nous avons retenu: -> ne pas attendre un quelconque SNMP trap ou mail d'alerte de l'onduleur -> mettre une marge très basse dans la supervision des batteries, du genre pour 21°C en moyenne, considérer l'alerte à partir de 24°C Bon Week-End. -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Starlink de Elon Musk arrive en France !
Le 09/03/2021 à 16:14, Michel Py via frnog a écrit : Kevin LABÉCOT a écrit : De mon côté je suis à 27km de la base terrestre de Villenave d'Ornon qui serait terminée d'après le journal Sud Ouest. Je suis inscrit depuis l'ouverture des "inscriptions" en France... Wait & See Un satellite Starlink c'est environ 20G de bande passante (quand il fait beau); reste à voir combien de clients ils vont mettre dessus. La France (surtout le Nord) est bien placée, la meilleure couverture possible est au alentours du 50ème parallèle donc même aujourd'hui il y a couverture permanente. Mais 20G pour couvrir l'ensemble du territoire, ça fait pas un nombre illimité de clients. Si on parle de 20 Gbps, ça fait environ 6 666 clients Netflix... Pour le calcul à l'arrache: -> environ 3 Mbps par client : https://ispspeedindex.netflix.net/country/france/ -> 20 000 / 3 = 6 666 La fibre et l'ADSL ont un bel avenir ;-) -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] peering (was BGP internal routes et external routes)
Bonjour, Le 28/02/2021 à 04:34, Michel Py via frnog a écrit : David Ponzone a écrit : En GP, j’en parle même pas, on pourrait presque vivre sans transit avec 10 peelings :) J’exagère, à peine... Pas ici; j'ai l'impression que la notion même de peering est en train de disparaitre. Ici, pour peerer il faut souvent payer, à un niveau qui fait que ça ne vaut pas souvent le coup et qu'acheter du transit est souvent préféré. En France aussi, le tarif IX est kif kif avec le tarif de certains transits. Pour les débits inférieurs à 40G, tu trouves plusieurs opérateurs de transit moins chers. Et à partir de 40G, cela peut repasser un peu en faveur des IX. Je pense que tout est question d'échelle et de ratio, dans une même zone géographique: - combien vas-tu avoir de clients potentiels pour un IX ? - combien vas-tu avoir de clients potentiels pour un transit ? 10, 100 ou 1000 fois plus de clients pour un transit ? Dans ce contexte, avec un trop faible volume de clients, cela me parait difficile d'être rentable pour un IX, et le prix s'en ressent. Aujourd'hui le prix reste un facteur déterminant : Combien de nos confrères hébergeurs ont envisagés de faire du peering, mais trop peu consommateurs, sont restés sur leur transit à quelques centaines d'Euros ? Concernant la disparition de la notion de peering, j'espère que cela ne se produira pas. Je vois plus le peering et les IX comme des opportunités techniques et relationnelles non offertes par les transitaires. Technique : maitrise de l'infra, optimisation des chemins, etc. Tu peux agir sur les annonces de ton AS sein de l'IX avec une finesse jusqu'à l'AS tiers, par exemple limiter/isoler un dysfonctionnement/surcharge pour favoriser un meilleur chemin. Relationnelle : échanges humains avec tes pairs (à l'instar de FRNOG) Les IX que je connais, organisent des réunions pour te permettre de rencontrer/discuter avec tes confrères : technique, retour d'expérience, business, etc. Bon Week-End ensoleillé :-) -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Re: 1.1.1.1 sur France-IX
Bonjour, Le 13/01/2021 à 17:16, David Ponzone a écrit : Et pour compléter, est-ce que d’autres ont constaté un problème en cours entre OpenTransit et Cloudflare ? De mon côté: BGP routing table entry for 1.1.1.0/24 IX Grenoblix 13335, (aggregated by 13335 141.101.67.1) 77.95.71.252 from 77.95.71.5 (77.95.71.5) Community: 0:15169 13335:10019 13335:19020 13335:20050 13335:20500 13335:20530 43100:1080 43100:1120 43100:9210 43100:9220 43100:65001 Ca passe par le router inter-IXP pour Grenoblix. Orange 3215 5511 13335, (aggregated by 13335 141.101.67.1) 193.253.157.242 from 193.253.157.242 (81.52.30.130) Ca passe par Open Transit pour Orange. Bon courage. -- * Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [JOBS] Postes d'administrateur système et réseau
Bonjour, Afin de renforcer l'équipe, nous recrutons plusieurs administrateurs système et réseau pour nos implantations en Métropole (Grenoble) et en Polynésie (Tahiti). Nous recherchons surtout des candidats motivés, ayant envie d'évoluer au sein de l'équipe. La porte est largement ouverte: nous accueillons les candidatures depuis le niveau débutant jusqu'à l'administrateur expérimenté (10 ans et +). Dans la description du poste ci-dessous, nous avons mis quelques exemples pour donner une idée sur les technologies employées. Il ne faut pas s'arrêter à ça, nous ne demandons pas de tout maitriser dès maintenant ou même du jour au lendemain. --- La société XSALTO située en région Grenobloise et bientôt en Polynésie Française recrute en CDI plusieurs administrateurs système et réseau Type de contrat : CDI à temps plein Lieu : région Grenobloise et Polynésie Française Niveau d'expérience : De débutant motivé à expérimenté Salaire: en fonction du profil et de l'expérience Date de démarrage souhaitée : dès que possible Intégré dans l'équipe hébergement et exploitation. Participe à l'exploitation et à l'administration dans deux centres de plusieurs centaines de serveurs. Astreintes non présentielles avec interventions sur site, une semaine sur 3 ou sur 4. Sous la responsabilité du directeur technique de l'activité. Les tâches incluent : Installation, exploitation et administration des routeurs (en particulier: BGP et OSPF) des firewalls réseaux, systèmes et applicatifs de solutions de virtualisation vmware et kvm de serveurs et VM essentiellement linux de stockage local, iSCSI et Ceph des équipements réseaux (en particulier: VLAN et VXLAN) des serveurs de sauvegarde Développement (bash, python, php...) de scripts systèmes d'extensions du portail de gestion de comptes client Contacts téléphoniques et mail support des clients internes et externes (en français et en anglais) relation avec les fournisseurs et opérateurs (en français et en anglais) Profil Passionné de système, sécurité et réseau Parle un anglais technique correct Lit l'anglais technique couramment Forte capacité à travailler en équipe, écoute Rigueur dans le suivi et la rédaction des procédures Capacité à assister téléphoniquement des clients Pour postuler: person...@xsalto.com --- N'hésitez pas à me contacter en mail privé pour toute précision. Merci. -- * Emmanuel DECAEN - Société XSALTO* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Réseau sur m1000e avec carte méconnue
Le 29/10/2020 à 11:42, Wallace a écrit : > Pourquoi bof bof ces cartes? On va faire une aggre plus trunk pour des > hyperviseurs, partie IP et iscsi dans ces tuyaux, elles ont > l'offloading iscsi et rien vu de bloquant à priori. > Sinon tu conseillerais quoi? Pour contourner le problème avec la virtualisation Proxmox et VLAN, je suis passé sur des Intel X520. -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Réseau sur m1000e avec carte méconnue
Bonjour, Le 29/10/2020 à 11:32, Maxime De Berraly a écrit : > Broadcom et Qlogic se sont revendus des gammes de NIC il y a quelques > temps. Ce sont bien des cartes Broadcom 57810 a l'origine, mais aujourdh'ui > c'est Qlogic qui fournit les drivers Dans les docs historiques tu la > trouvera sous la marque Broadcom, mais plus sur leur site. Elle est bien > compatible avec les passthru comme avec les MXL. > Ca reste des cartes bof bof, mais ca tourne. Et à moins d'un changement récent, c'est pas la joie avec Proxmox et les VLANs: https://forum.proxmox.com/threads/broadcom-10g-nic-does-not-work-with-vlans.49631/#post-266066 Bon courage. -- Emmanuel DECAEN --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] UDP - DDOS : Solution globale possible ?
Bonjour, Le 03/09/2020 à 09:48, Fabien H a écrit : > je rebondis sur le sujet précedent avec ce sujet : j'ai peur de lancer un > gros troll mais pour être sur que c'est techniquement impossible je demande > quand même : > > Les attaques DDOS les plus méchantes se font en UDP pour les raisons qu'on > connait : usurpation de l'IP source car pas de contrôle de sa validité sur > ce protocole + amplification sur les services ouverts sur Internet > > Ma question est simple et innocente : si tous les opérateurs mondiaux (et > notamment les hébergeurs de serveurs VPS mais pas que) se mettaient > d'accord sur des ACL (voir QoS rate limit sur certains flux UDP) bien > pensées à appliquer en routeurs de bordure, peut-être pourrait on endiguer > le phénomène ? Côté usurpation, pour réduire la voilure, une première étape importante consiste à suivre BCP 38. https://www.bortzmeyer.org/bcp38.html Tu ne laisses plus sortir de paquets usurpés de ton réseau ! Et si tout le monde le fait, cela complique singulièrement la tache de l'attaquant :-) Certes, ce n'est pas forcément évident pour un tier 1 (ou équivalent), mais pour les autres, c'est un effort à faire. -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Solution FS.COM
Bonjour, Le 10/07/2020 à 10:27, Romain Guitteau a écrit : > Nous devons acheter des switchs pour un datacenter. Nous avons vu le site > fs.com, est-ce que les produits sont fiables et correct ? En switch, j'ai acheté uniquement des modèles PoE chez eux. Pour le moment, pas de problème de fonctionnement à noter avec les caméras (Hikvision), les bornes wifi (Ubiquity) , les bornes téléphoniques (Gigaset) et les téléphones (SNOM). Mon seul regret est qu'il n'est pas rare qu'une référence est une durée d’existence un peu courte chez FiberStore. Concrètement, tu veux re-commander le même switch, et tu découvres qu'il n'est plus disponible à la vente. Ce n'est pas forcément gênant, mais il faut maintenir un dépôt des versions firmware pour chaque modèle de switch, idem pour la configuration. Le problème est également présent pour d'autres produits, comme les MUX, où le tiroir a changé. Tu te retrouves avec un tiroir multi-slot qui ne peut plus accueillir les nouveaux MUX. C'est également vrai pour les cassettes MTP très haute densité, on ne peut plus commander le chassis ou la cassette après 2 ans. Il faut juste en être conscient, et s'organiser en conséquence :-) -- Emmanuel DECAEN --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Choix de routeur en 2020
Bonjour, Le 03/07/2020 à 08:03, Xavier Beaudouin a écrit : >> Je ne sais pas quel est son état d'avancement dans FRR. Quelqu'un l'utilise >> aujourd'hui ? > Là dessus je me pose exactement la même question, parce bon OSPF ca marche > (des fois > mais IS-IS c'est bien sympa...). De mon côté, je n'ai pas eu de soucis avec OSPF en IPv4 sur FRR, c'est la partie IPv6 qui pose problème. C'est dommage pour l'adoption de IPv6 et de FRR ! En attendant voici la méthode pour "réparer" le problème quand il se produit sur FRR: $ sudo pkill ospf6d => watchfrr le relance automatiquement. C'est un tantinet brutal, mais au moins ça refonctionne. Concernant IS-IS, je n'ai pas essayé car j'avoue être plus habitué à OSPF. Je m'étais dit que j'allais peut-être remplacer OSPF par IS-IS sur nos Nexus 9300, ce sera une bonne occasion pour regarder de plus près le protocole :-) Bon Week-End. -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Choix de routeur en 2020
Bonjour, Bug OSPF pour IPv6 sur FRR ouvert depuis 2018: https://github.com/FRRouting/frr/issues/2303 Je suis disponible pour les tests si besoin. -- Emmanuel Le 02/07/2020 à 08:25, Sébastien 65 a écrit : > Rémy, > > Quel est exactement le problème avec OSPF en IPv6 avec FRR ? > > *De :* frnog-requ...@frnog.org de la part de > Duchet Rémy > *Envoyé :* jeudi 2 juillet 2020 08:09 > *À :* Emmanuel DECAEN ; frnog@frnog.org > > *Objet :* RE: [FRnOG] [TECH] Choix de routeur en 2020 > > > > Avec FRR, la partie BGP me convient très bien, malheureusement la > partie OSPF avec IPv6 pose vraiment problème. > > Perso, FRR ne fonctionnait pas en BGP sur un Bond Linux en 2x10Gbps. > > Rémy > > --- > Liste de diffusion du FRnOG > https://eur06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2Fdata=02%7C01%7C%7C16315b0720844e21857808d81e4e9374%7C84df9e7fe9f640afb435%7C1%7C0%7C637292670111418232sdata=RfmLk37iU%2BrcEXcKh3RVBZVL9o7El7J3RomcPcW%2FHrU%3Dreserved=0 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Choix de routeur en 2020
Bonsoir, Le 30/06/2020 à 17:36, Wallace a écrit : > Voici mon constat, on doit remplacer notre infra Cisco / Juniper de core > router mais on les aime de moins en moins, on ne supporte plus les > limitations par licences alors que le matériel sait faire le boulot, > forcément on paye les composants. Le licencing est devenu complexe et > deux équipements sur une étagère où l'on pense qu'on peut faire la même > chose et ben en fait non pas du tout, c'est pénible, la gestion du stock > devient de plus en plus complexe. > > On aimerait partir sur du open hardware network pour avoir un prix juste > en neuf, notre besoin serait d'être capable de router du 40Gbps chacun, > d'avoir full view ipv6 ipv4, d'être automatisable par du Ansible ou > fichier à plat qu'on pousse, sflow, je sais pas si ça existe mais un > exporter Prometheus plutôt que du snmp. Tout n'est pas perdu, peut-être un jour le meilleur des deux mondes: https://blogs.cisco.com/sp/cisco-goes-sonic-on-new-networking-platforms Si Cisco avance sur ce sujet, tu pourras réutiliser ton matériel sans dépendre des licences ou mises à jour logicielle IOS ou NXOS. Et là pour le coup, tu peux faire tourner ton BGP en FRR avec de l'ASIC connu en dessous ;-) Par contre côté CLI... il va falloir s'habituer au changement. -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Choix de routeur en 2020
Bonsoir, Le 01/07/2020 à 19:01, David Ponzone a écrit : >> Intel et Mellanox ont des cartes 100G qui marchent avec DPDK; attention >> c'est du PCIe v3 16x donc faut avoir les bons slots, mais çà fait 100G; >> d'après ce que j'ai vu çà commence à tomber s'il n'y a que des paquets de 64 >> octets, mais avec un mix normal çà passe 100G linerate. > Je le redis, faut essayer 6Wind. Prix raisonnable (au throughput, déclaratif) > compte tenu du produit et du support . Je n'ai pas testé 6Wind, mais pourquoi pas :-) Pour le moment, j'ai juste du VPP en lab avec des cartes 2x10 Gbps. J'ai pas mal galéré au début avec VPP sur de mauvaises cartes "Intel". Pour ne perdre de temps, il est impératif d'avoir les bonnes cartes (cf. doc VPP et DPDK)... Au niveau test de performance, c'est plutôt marrant, je sature les outils de test avant de saturer les cartes ! Il me reste à faire le pas d'un passage sur un bout de production, et là, je suis plus prudent ;-) > David Ponzone a écrit : >>> Perso, tu pourras me mettre un proc à 5Ghz et 32Go de RAM, j’ai vu des bugs >>> tellement >>> pas propres dans le routage (OSPF entre autres), que j’ai dû passer en RIP Ce n'est pas tout à fait le seul. Avec FRR, la partie BGP me convient très bien, malheureusement la partie OSPF avec IPv6 pose vraiment problème. -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Câbles DirectAttach 25G pour hpe ?
Bonjour, Le 12/06/2020 à 15:56, David Ponzone a écrit : > Tiens, dans la famille des trucs pénibles, les DAC 10G FS ne marcheraient pas > sur un ASR-1001X alors que ça passe sur un Nexus….. D'ailleurs j'ai été surpris que des DAC 10G FS codés "Dell" fonctionnent (sans recodage) entre deux Cisco Nexus 9372. -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Contact Free
Bonjour, Le 09/06/2020 à 16:04, Oliver varenne a écrit : > Ok c'est bien ce qu'il me semblait > Ils ont repris les travaux dans le vieux village depuis quelques semaines > Je pense que vu ma maison, je serai le dernier servi... (pas de fourreaux, > les lignes actuelles passent en aérien sur le mur des maisons, etc... donc > pas mal de choses à faire pour refaire au propre) De ce que j'ai pu en voir, si l'existant passe en aérien, ou sur le mur d'un maison, il y a un risque que cela ne change pas pour la fibre. Sur plusieurs déploiements successifs dans l'immeuble l'année dernière, toutes les fibres sont passées exactement au même endroit que le cuivre: en aérien, puis le long du mur du voisin d'en face. Et comme le tube sur le mur du voisin est devenu vite plein (à force d'ajouter des fibres à l'intérieur), les dernières fibres se sont retrouvées collées le long du tube. Le voisin a dû apprécier l'aspect esthétique des choses, sur son mur, à sa juste valeur ;-) Bon courage. -- Emmanuel DECAEN --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [MISC] Prochaine assemblée générale du RIPE - Vote pour le renouvellement de trois siège au board
Bonjour, Le 15/05/2020 à 14:28, Vincent Bernat a écrit : > Il faudrait faire tourner l'algo jusqu'au bout. En lisant le décompte > en diagonale, il était soit placé premier (parfois seul, parfois non), > soit placé dernier. On ne peut pas regarder les premiers tours pour > déduire sa place finale. Regarde Raymond Jetten qui a fait un très > mauvais score pour le première siège. Les votes individuels sont publiés sur le lien "Vote Verification Page" depuis cette page: https://www.ripe.net/participate/meetings/gm/meetings/may-2020/voting-report En nombre de votes, c'est intéressant. (Excusez la méthode imparfaite) $ grep "Christian" disclosevotes.txt | wc -l 1300 (dont 522 en 1ère place) $ grep "Raymond" disclosevotes.txt | wc -l 1000 (dont 135 en 1ière place) $ grep "Jordi" disclosevotes.txt | wc -l 869 (dont 95 en 1ière place) $ grep "Elad" disclosevotes.txt | wc -l 482 (dont 200 en 1ère place) Bon Week-End -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Routeur 4 G
Bonjour, Le 11/05/2020 à 15:13, x.r...@sipleo.com a écrit : > Plusieurs fois évoqué ici mais comme cela bouge dans ce domaine, je repose > la question avec un contexte un peu particulier. > > On cherche sans parler de budget car on cherche un modèle « universel » : > > * Qu’ils conviennent à toutes les fréquences de tous les opérateurs > (France pour le moment) > * Que l’on puisse lui changer d’antenne pour les déportés si > nécessaire > * Deux ports RJ de préférence ou plus > * Puisse faire aussi routeur LAN/WAN a travers un réseau local mais > devant s’authentifier sur un proxy pour l’accès Internet > * Watchdog et reboot auto > * Fiable / solide > * Solide Fanless milieu industriel > > Donc pour vous ce serait quoi la bête parfaite ? > > Teltonika, Huawei , Microtik … Si le prix n'est pas un problème, tu peux voir avec Etic Telecom, nous travaillons avec eux depuis bientôt 10 ans. https://www.etictelecom.com/fr/nos-gammes/routeur-industriel-gamme-ipl/ Ils sont français et disponibles pour discuter produit. Si besoin, je peux te donner un contact. Merci. -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les élections du RIPE
Bonsoir, Le 08/05/2020 à 20:35, Clement Cavadore a écrit : > En ce qui me concerne, je donnerai mon support à Christian Kauffman, > qui se présente à sa propre succession au sein du Board. Je ne le connais pas, mais ce que j'ai pu lire le concernant est plutôt positif. Je vais également voter pour lui. >> PS: If you don’t know for who else you wanted to vote, then please >> have a look at Sylvester and Maria background and motivation >> statements. Je pense également voter pour Maria Häll, sa biographie est intéressante et cela fera un peu de mixité. https://www.ripe.net/participate/meetings/gm/meetings/may-2020/candidate-biographies#maria_hall Bon Week-End à tous. -- *Emmanuel DECAEN * --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Prochaine assemblée générale du RIPE - Vote pour le renouvellement de trois siège au board
Bonjour, Le 01/05/2020 à 13:54, Clement Cavadore a écrit : > [...] si vous > avez un LIR de plus de 6 mois d'age, à aller voter lors de la prochaine > AG. En effet, le 13-15 mai prochain, au cours du prochain General > Meeting (qui se tiendra en téléconférence), il y aura une élection pour > le renouvellement de trois sièges au board executif du RIPE NCC. Je ne suis pas très fier de le dire, mais en une vingtaine d'années, je n'avais jamais pris le temps de voter au RIPE. Je rejoins Clément, je pense que le moment est venu, que chaque voix va compter. Voici les candidats: https://www.ripe.net/participate/meetings/gm/meetings/may-2020/confirmed-candidates Je vous encourage à vous enregistrer et à aller voter. Bon Week-End. -- *Emmanuel DECAEN * --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Trunk SIP redondant
Bonjour, Le 16/04/2020 à 09:54, David Ponzone a écrit : > J’avais pris la question d’Emmanuel comme une question concernant les > opérateurs, et je me rends compte qu’effectivement sa question portait > sur les trunks pour client finaux. En fait, les deux aspects m'intéressent et les deux réponses mes conviennent. > De toute façon la problématique reste la même, SIP reste SIP et copie > le fonctionnement du legacy en ISDN/SS7, et rien n’a été prévu pour > qu’une ressource téléphonique puisse être annoncée par 2 chemins. C'est entièrement statique ? Il n'y a pas moyen de dire techniquement "voici mes blocs" à l'opérateur upstream (ou un peer) ? > Sachant que l’opérateur qui détient la ressource touche en plus des > reversements sur les appels entrants, et que la quasi-totalité du > trafic utilise Orange (donc l’opérateur historique) comme transit > entre les opérateurs En gros, si je comprends bien, il existe toujours un gros monopole de fait avec Orange. > (il y a très peu de peering, il n’est pas gratuit par définition, au > mieux il y a compensation, et 3 ou 4 opérateurs cumulent 90% du > trafic; il y a un colistier qui a tenté de montre un point de peering > Voix: gros échec, il pourra peut-être nous donner sa vision du > problème), on sent bien qu’on est sur un modèle très différent de > l’IP, et je vois mal un changement à ce niveau à court-terme. Et j'imagine que parler de l'aspect ci-dessous est un peu polémique ;-) $ whois 3.3.e164.arpa. domain: 3.3.e164.arpa descr: domaine enum de la France, France Metropole remarks: Website: http://www.telecom.gouv.fr/ remarks: Email: admine...@industrie.gouv.fr Bonne soirée. -- *Emmanuel DECAEN* E-Mail: e...@xsalto.com www.xsalto.com Tél: 04 92 36 60 06 Support: 04 92 36 60 07 Fax: 04 92 36 19 75 --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] Trunk SIP redondant
Bonsoir, Existe-t'il une solution pour avoir un Trunk SIP redondant pour les appels entrants pour un bloc donné de numéros ? En gros je prends un premier trunk SIP auprès de l'opérateur A et un second trunk SIP auprès de l'opérateur B. En temps normal, je reçois les appels depuis A et/ou depuis B. En cas de problème avec A, je reçois immédiatement les appels depuis B (et vice versa). En gros, cela revient au mécanisme de BGP appliqué à la téléphonie. Est-ce que cela implique d'avoir mes propres ressources en numérotation (équivalent PI en IP) ? Ou existe t'il des loueurs de blocs de numéros (équivalent LIR pour la location d'un bloc IP /24) ? Merci. -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Téléphonie IP DECT
Bonsoir, Le 15/03/2020 à 18:12, David Ponzone a écrit : > Pour moi, la raison principale, c’est qu’avec Gigaset, on a un combiné à > moins de 60€, voir moins de 50€ par moment. > >> Le 15 mars 2020 à 18:07, Oliver varenne a écrit : >> >> Vais prêcher pour ma paroisse, mais ... >> Pourquoi pas autre chose que du gigaset ? Il y a trois raisons me concernant: le parc, la fiabilité et le prix. Côté parc, j'ai de la téléphonie IP (siemens) Gigaset depuis 2006... Et donc j'ai toute une flopée de combinés Gigaset, en partant du C45 jusqu'au S650 Pro. Conserver du Gigaset me permet de garder l'existant sans contrainte. Il faut noter que les C45 ont bientôt 15 ans, et même s'ils sont vieillissants, ils fonctionnent toujours bien. Vendredi matin, j'ai massivement distribué les anciennes bornes DECT IP (C455IP, S685IP, etc.) aux télétravailleurs, afin qu'ils puissent travailler de chez eux comme s'ils étaient au bureau. Chaque salarié est parti chez lui avec son propre combiné DECT, il conserve son numéro de téléphone. Pour répondre aux questions reçues en privé: J'utilise ces bornes avec un PBX IP Asterisk. Le gestionnaire des bornes N720 est très simple à configurer (même plus simple qu'un N510 à mon gout), et l'ajout d'une nouvelle borne DECT se fait très facilement (solution multi-cellules). Si quelqu'un a du N870, je suis vraiment preneur d'un retour d'expérience. Merci. -- Emmanuel DECAEN --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] Téléphonie IP DECT
Bonjour, Actuellement pour la téléphonie IP DECT, je mets du Gigaset IP Pro N510 pour du petit site et du N720 pour du site plus gros. C'est fiable et ça marche bien; en bref j'en suis globalement très satisfait. Je prévois d'évoluer vers du N870 IP Pro en configurations "Small" et "Medium": https://www.gigasetpro.com/fr/systemes/details-du-systeme/product/n870ip-pro/ En avez-vous déjà installé ? Avez-vous un retour d'expérience dessus ? Est-ce aussi simple que du N720 en terme de mise en oeuvre ? Bon Week-End. -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [TECH] Demande de vidage partiel de caches DNS
Bonjour, Le 19/02/2020 à 09:26, Stephane Bortzmeyer a écrit : > Des domaines comme louvre.fr n'ont pas été changés du tout > et ont quand même eu le problème.) > [...] > (Par exemple, genethon.net a été également affecté.) Ca se précise :-) S'agit-il uniquement des DNS du prestataire ? > % dig +short NS assemblee-nationale.fr > ns1.fr.claradns.net. > ns0.fr.claradns.net. > ns2.fr.claradns.net. Merci. -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Deploiement WIFI
Bonjour, Le 07/02/2020 à 11:15, Philippe ASTIER a écrit : > Hello, > > pour déployer et gérer régulièrement de l’Unifi, y compris hôtel et > restaurants, quelques remarques côté « negatif » : > > - aucun souci de mon côté sur iOS. Souci de paramétrage ? firmware ? > contrôleur ? Sur plusieurs iphones, les utilisateurs concernés ont du retenter plusieurs fois la première connexion (jusqu'à 10 fois pour un vieil iPhone) afin que cela fonctionne, c'est assez déroutant comme comportement. Une fois que c'est paramétré, plus de soucis, le téléphone se connecte et se reconnecte sans problème. Comme il m'a été suggéré hors liste, je vais faire configurer manuellement le réseau sur les iPhones et voir si cela évite le problème. > - oui, le provisioning s’applique simultanément à toutes les bornes (c’est > pas un reboot complet heureusement). A suggérer dans les forums, je vais > faire une feature request de ce pas, c’est une super idée. :) > - le portail invité, par définition, n’est pas sur le même subnet ou VLAN (ou > les deux bien sûrs), donc il est NORMAL et même rassurant que les imprimantes > (souvent gérées en multicast via Zeroconf (ex. bonjour) ne soient pas > fonctionnelles). En revanche, sur un même réseau (ex: réseau prod ou admin), > il n’y a aucune raison pour que l’impression ne fonctionne pas. Je parle bien de l'impression depuis le réseau Wifi entreprise (et pas depuis le réseau Wifi invités). Il y a beaucoup de gens dans la même situation avec les imprimantes HP sur les forums Ubiquiti. Pour contourner le problème, j'ai fini par désactiver le "Enable Multicast and Broadcast Filtering" sur le réseau Wifi invités (portail invités) pour que cela fonctionne de nouveau pour les utilisateurs du réseau Wifi entreprise. C'est assez déroutant car la configuration est individuelle et qu'elle a un effet sur les petits copains ;-) On peut en discuter en privé, si tu veux. L'aspect sympa que j'ai oublié de mentionner, c'est que la configuration est cohérente entre tous les sites locaux ou distants, qu'ils soient microscopiques (une borne) ou importants (multi bornes). Complété par l'authentification sur le Radius utilisateur (avec mot de passe individuel), cela permet de gérer facilement le déplacement des salariés sur les différents sites sans la moindre intervention. Merci. -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Deploiement WIFI
Bonjour, Le 07/02/2020 à 10:05, David Ponzone a écrit : > Ca dépend du budget et du besoin. > > Si dépenser 500-1000€ par borne sur 3/5 ans, ça te fait pas peur -> > Ruckus/Aerohive > Si tu voyais plus 100-200€ -> Ubiquiti > > Si le besoin n’est pas ultra-critique (le handover en WIFI, c’est quand même > de la branlette dans 95% des cas) -> Ubiquiti On utilise Unifi avec un réseau "entreprise" en WPA2 Entreprise (Contrôleur Unifi + Radius) et un réseau "Invités". Pour le moment, mon expérience est plutôt mitigée. En positif: + Une fois connecté au Wifi, la connexion est fiable et stable + L'indication du niveau de qualité pour chaque PC ou Smartphone connecté facilite énormément le support + L'ajout d'une borne est très rapide et très simple + Le contrôleur est gratuit et installable sur une Debian de base En négatif: - certains Smartphones (iPhone par exemple) rencontrent de vrai difficultés à établir la première connexion en Wifi - la modification de configuration fait rebooter toutes les bornes, plutôt que de le faire une borne à la fois (automatiquement) - l'activation du réseau "Invités" a des effets de bord fonctionnels sur les autres réseaux (pb d'impression par exemple) Il est possible que sur les points négatifs, j'ai juste loupé un truc, il ne faut pas hésiter à me dire s'il y a une solution miracle. Merci. -- * Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] FSOS vs BGP
Bonsoir, Le 29/01/2020 à 17:39, Michel Py a écrit : >> Emmanuel DECAEN a écrit : >> Extrait de https://www.fs.com/fr/products/29124.html : >> J'avoue avoir été surpris par la réponse de FS sur la capacité BGP de ce >> switch : "8k IPv4 route" et "can hold a Full BGP table" > Ils n'ont visiblement aucune idée de ce que c'est un full feed. > Pareil pour stacking : ils te sortent MLAG pour la question, quand tu > regardes de près il n'y a même pas de connecteur pour le stacking. > Si tu regardes la vidéo de leur MLAG, il y a clairement 2 switches, alors > qu'un stack cà apparait comme un seul. Ils savent pas ce que c'est un stack > non plus. La solution FS ressemble au MLAG de Cumulus (interco se fait au travers de ports classiques): https://docs.cumulusnetworks.com/cumulus-linux/Layer-2/Multi-Chassis-Link-Aggregation-MLAG/ > C'est assez typique de fs.com. Je suis un client satisfait, pour les > optiques, les cables, etc je regarde même pas ailleurs mais faut pas faire de > trucs compliqués avec eux; c'est à chacun de faire sa propre opinion si le > produit répond au besoin. Idem de mon côté, pour le moment ça se cantonne aux optiques, certains câbles et un peu de matériel bureautique de base. Ceci étant dit, mon petit doigt me dit que certains de leurs switchs 100G vont sortir avec SONiC, et là je vais peut être jeter un oeil en lab ;-) Merci. -- *Emmanuel DECAEN* E-Mail: e...@xsalto.com www.xsalto.com Tél: 04 92 36 60 06 Support: 04 92 36 60 07 Fax: 04 92 36 19 75 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] FSOS vs BGP
Bonjour, Le 28/01/2020 à 15:28, Kevin Thiou a écrit : > j'ai depuis peu un switch/routeur FSOS Software, S5850, Version 7.2.1 > > J'ai configuré BGP dessus, les sessions EBGP montent parfaitement, je > reçois les routes des peer externes. > > J'ai aussi configuré mes peer IBGP, les sessions sont montées et je reçois > bien les routes des différents peer. J'avoue avoir été surpris par la réponse de FS sur la capacité BGP de ce switch : "8k IPv4 route" et "can hold a Full BGP table" Extrait de https://www.fs.com/fr/products/29124.html : "1. It can support up to 8k IPv4 routes and 1536 IPv6 routes. [...] 3. Yes, the switch can hold a full BGP table." [...] > Par contre je n'envoie rien vers mes peer IBGP, j'ai retiré toutes les > prefix-list et autre route-map mais rien n'y fait. > > Une idée d'un oublie bête avant de rentrer dans le détail de la conf ? Peux-tu donner ta configuration BGP ? Merci. -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Mifare et CSN
Bonjour, Le 22/11/2019 à 11:59, David PACHOLEK a écrit : > [...] > > C'est bizarre de proposer des mifare classic de nos jours, sachant qu'elles > sont 100% crackable (presque) facilement. > La solution si tu veux utiliser juste des cartes RFID c'est d'utiliser ou > bien des Mifare Plus, ou bien des Mifare Desfire (souvent utilisé en DC), > il n'existe pas (encore) de solution pour les copier, a condition > d'utiliser un password qui ne soit pas celui par défaut bien sur. Aujourd'hui, il me parait plus raisonnable de partir sur du Mifare Desfire plutôt que du Classic. Des gens comme Siemens proposent la solution Vanderbilt (cité dans un précédent message) sur leur offre de base. En mode Desfire, le traitement est un tout petit peu plus lent sur le lecteur de badge, mais de toute façon si c'est associé à un code PIN, c'est la saisie du code qui prend du temps :-) -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Multihoming BGP avec COGENT en principal et SFR en backup
Bonsoir, Le 07/11/2019 à 18:42, Jérôme Nicolle a écrit : > Salut Raphaël, > > Le 07/11/2019 à 14:43, Raphael Mazelier a écrit : >> Le volume principalement. (taille des tuyaux et société) C'est effectivement ce que je soupçonne. Et quand je vois l'insistance de certains, je me demande s'il n'y a pas aussi un souhait d'acquisition de clients coute que coute. Je n'ai pas encore eu de proposition à 100 € pour 1 Gbps, mais cela me laisse quand même un peu songeur. Comment financer un support compétent avec un tel tarif, le moindre problème ou appel d'un client et son traitement, mange l'intégralité de la marge. >> >> Et aussi les tier1 ne fournissent pas le même service par nature. >> >> En résumant grossièrement un tier1 va pouvoir évacuer beaucoup de trafic >> de manière non optimale. >> >> Un tier2 va pouvoir évacuer moins de trafic (car il n'est pas sizé pour) >> mais de manière plus optimale, car théoriquement il doit avoir un réseau >> avec plus de capillarité. Avec des particularités locales : comme un Tier 1 intégrant dans son backbone un Tier 2 local ;-) > Réponse parfaite. C'est bien le cas, sur tes trois points, mais > peut-être peut-on compléter : > > - Un Tier 1 est trop gros pour te fournir du service custom, c'est un > vendeur de "Fat Pipe". Le jour ou tu te fais DDoSer, t'es tout seul, il > ne le verra pas dans ses graphes. J'ai l'impression que s'agissant de DDoS, il s'agit plutôt d'une construction différente de l'offre de service pour les Tier 1. Les quelques Tier 1 avec lesquels j'ai pu échanger récemment, proposent en majorité une offre à tiroir avec: le transit, la détection DDoS et le nettoyage via les scrubbing center locaux. Certes les tarifs ne sont pas le même selon le niveau de protection attendu, mais globalement c'est disponible. Je n'ai pas encore eu l'occasion de tester leurs offres, je suis donc bien en mal de pouvoir donner un retour d'expérience dessus. > Perso, les emmerdes ne me font pas peur. Mais au quotidien, pour assurer > la qualité du sommeil des membres d'un NOC, il faut vraiment réfléchir à > ces choix de transitaires. Et il faudrait, pour certains, qu'ils soient > plus transparents. Je partage ton avis. Un de mes critères de choix (parmi d'autres) est la capacité à faire de l'ingénierie de trafic sur le réseau du transit. J'ai demandé des choses assez simples comme des communautés "do not announce", "prepend", "blackhole", etc. La grande majorité des Tier 1 et Tier 2 propose ces communautés, mais avec un niveau de granularité très différent. Pour certains opérateurs ces communautés peuvent cibler avec un niveau de finesse allant jusqu'à l'AS. Par exemple: "2 prepend" de mon préfixe pour l'AS y uniquement Pour d'autres opérateurs, la granularité s'arrête à un point de peering ou un continent et rien au niveau de l'AS. Par exemple: "do not announce" mon préfixe sur le point de peering z. Et enfin certains opérateurs ne proposent aucune communauté, même pas le blackhole, et de nos jours, cela me parait quand même un peu difficile à comprendre. -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Multihoming BGP avec COGENT en principal et SFR en backup
Bonjour, Le 07/11/2019 à 13:27, Hugues Voiturier a écrit : > Sinon aujourd'hui, à ~350€ le port 10G commit 1G chez un Tier-1, à peu près > partout en France, c’est pas du luxe d’en prendre deux, à mon sens… D'ailleurs, c'est assez surprenant de constater que les Tier 1 paraissent globalement nettement moins chers que les Tier 2. J'ai du mal à m'expliquer ce phénomène, j'imagine que tout est question de volume... Concernant la disponibilité à peu près partout en France, je suis un peu plus mesuré: Encore faut-il que le Tier 1 s'implante dans ta zone géographique, sinon les frais de liaison risquent de plomber un peu la facture ;-) Le 07/11/2019 à 11:33, Eddy Minet a écrit : > Je suis en train de me casser la tête pour avoir un peer BGP SFR en rôle de « > backup » et malgré le prépend qui est fait à la fois sur notre AS et sur > celui de SFR j’ai toujours un gros pourcentage du traffic dessus. > Il semble que les routes via SFR même 3 fois plus longues soient préférées > chez la plupart des autres AS. > Sur les looking glass je m’aperçois que la local preference est quasiment > toujours meilleure sur le peering SFR. > Y a-t-il une communauté magique pour agir là-dessus ? Pour la communauté magique, il faut demander à tes transits, la liberté offerte pour l’ingénierie réseau (do not announce, prepend, etc) est très variable selon l'opérateur concerné. Concernant l'architecture, la solution avec deux (ou +) transits différents en actif/actif me parait la meilleure pour avoir une bonne disponibilité. Et idéalement, si tu as un bon IX a deux pas de chez toi, un peu de peering bien géré peut être un vrai plus. Bon courage. -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Discussion technique
Bonjour, Le 03/11/2019 à 20:26, Guillaume Barrot a écrit : > Pour 1000 balles sinon tu as un serveur blindé gavé de CPU et d'interfaces > 10G (typiquement 3/4 cartes 2 x 40G + breakout). > Ensuite, Linux + FRR + VPP + DPDK (ouais il reste 99% du boulot quoi). J'en entends beaucoup parler, il reste juste à franchir le pas ! Quelqu'un a retour d'expérience sur Linux + FRR + VPP + DPDK ? Autant FRR, malgré quelques bugs (parfois pénibles), fonctionne bien. Autant sur la partie VPP + DPDK, je suis intéressé par l'idée, mais j'ai plus de mal à franchir le pas. Une idée sur la facilité d'exploitation et sur la stabilité ? > Pour la partie PPP, tu peux aller sur AccelPPP (merci Bretagne Télécom au > passage) Intéressant ! Est-ce que Accel-PPP est plus performant et plus stable qu'un libreswan+xl2tpd ? Merci. -- Emmanuel DECAEN --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] SONiC sur Dell S4048
Bonjour,
Le 18/09/2019 à 20:45, Michel Moriniaux a écrit :
> vous pouvez essayer bcmcmd "show params" | grep chip
J'ai lancé la commande depuis opx:
grep chip:
chip trident2 xgs xgs3_switch xgs_switch
head:
driver BCM56850_A0 (trident2)
regsfile TRIDENT2 final
pci identifier vendor 0x14e4 device 0xb850 rev 0x01
classes of service 8
maximums block 118 ports 267 mem_bytes 80
blk 0 cmic0 schan 5 cmic 5
blk 1 cport0 schan 14 cmic 14
[...] (plus de 500 lignes derrière)
> donc si effectivement c'est un TDII sans l'appui de dell ca va être
> compliqué:
> si vous regardez le repo sonic-buildimage vous trouverez
> l'arborescence "device"
> device va contenir des répertoires organises par constructeur
> dans le dossier constructeur (ex: dell ) vous allez trouver les séries
> par ex le s6000
> dans le dossier d'une série se trouveront:
> - les configurations matériel génériques: le fichier de conf pour
> lm-sensors, la config pour les leds, des scripts spécifiques pour le
> reboot ou l'intaller par ex.
> - les "géométries" ce sont des sous dossiers qui vont décrire comment
> sont configures les ports ( si vous vous souvenez pendant la prez on a
> précise que sur certains ASIC il n'était pas possible de reconfigurer
> la vitesse ou le breakout des ports ). ces géométries sont ce qu'on
> appelle les HWSKU
> dans ces dossiers HWSKU (par ex: Force10-S6000-Q32/ un S600 configuré
> en 32*40G ) vous aller trouver:
> - 2 fichiers magiques: port_config.ini et blabla.bcm ces fichier
> contiennent tous les registres utilises par SAI et le driver Broadcom
> pour configurer l'ASIC. c'est vraiment la config qui définit comment
> les pinoches de l'ASIC sont connectées au reste du boitier, seul le
> constructeur connaît ça ( vous pouvez aussi vous armer d'un tournevis
> et d'une loupe et essayer de suivre les traces... mais je ne le
> conseille pas)
>
> donc pour faire le portage il va falloir créer un dossier série suivi
> d'un dossier hwsku. sans l'aide du constructeur c'est sport.
Cela me semble d'autant plus délicat que, si je comprends bien, le
dossier modules contient un module noyau en C spécifique à l'équipement.
Pour le module du Dell S6000, c'est Microsoft qui semble être l'auteur :
https://github.com/Azure/sonic-buildimage/tree/master/platform/broadcom/sonic-platform-modules-dell/s6000/modules
MODULE_AUTHOR("xxx yyy "
>
> vous pouvez déjà essayer de lancer un 'show platform summary' et 'show
> platform syseeprom' et pourquoi pas un 'sensors' pour voir ce qui est
> réellement détecté. pour l'instant a mon avis le sonic ne connaît que
> le CPU et les éléments 'génériques'
$ show platform summary
Warning: failed to retrieve PORT table from ConfigDB!
Platform: x86_64-dell_s4000_c2338-r0
HwSKU: Unknown
ASIC: broadcom
Le show platform syseeprom dépend de l'arborescence à créer dans
platform; en utilisant ONIE:
$ onie-syseeprom
TlvInfo Header:
Id String: TlvInfo
Version: 1
Total Length: 152
TLV Name Code Len Value
--- -
Product Name 0x21 7 S4048ON
Part Number 0x22 6 0V92WC
Serial Number 0x23 20 xx
Base MAC Address 0x24 6 xx:xx:xx:xx:xx:xx
Manufacture Date 0x25 19 03/21/2019 11:15:37
Label Revision 0x27 3 A01
MAC Addresses 0x2A 2 256
Manufacturer 0x2B 5 28298
Country Code 0x2C 2 CN
Service Tag 0x2F 7 xx
Vendor Extension 0xFD 7 0x00 0x00 0x02 0xA2 0x2D 0x46 0x46
Platform Name 0x28 26 x86_64-dell_s4000_c2338-r0
ONIE Version 0x29 10 3.21.1.0-5
CRC-32 0xFE 4 0x53C0F373
Checksum is valid.
$ sensors
coretemp-isa-
Adapter: ISA adapter
Core 0: +27.0 C (high = +98.0 C, crit = +98.0 C)
Core 1: +25.0 C (high = +98.0 C, crit = +98.0 C)
Merci.
-- *
Emmanuel DECAEN*
---
Liste de diffusion du FRnOG
http://www.frnog.org/
Re: [FRnOG] [TECH] SONiC
Bonjour Michel, Le 18/09/2019 à 17:44, Michel Moriniaux a écrit : > c'est une question a poser directement a Dell. > Je doute que vous puissiez y arriver cela dit car ce switch est a base > de Trident et cet ASIC n'est pas supporté par les couches SAI BRCM de > sonic > les Asic Broadcom les plus anciens supportés sont les Trident2 et > Tomahawk. Il me semble que nous sommes en Trident 2 sur le S4048. Je viens de jeter un oeil sur les HCL de Pica8, Cumulus Linux et ipinfusion, à priori, c'est bien indiqué Trident II (BCM56850). https://cumulusnetworks.com/products/hardware-compatibility-list/ https://www.ipinfusion.com/hardware-compatibility-list/ SONiC est installé sur le S4048, si il y a une commande magique dans SONiC pour confirmer, je suis preneur :-) Merci. -- Emmanuel DECAEN --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] nOS gratos pour ONIE/Trident2+
Bonsoir, Le 16/09/2019 à 17:47, Clément Gineste a écrit : > Vous connaissez des network OS pour switch bare metal avec ONIE qui > seraient gratos ? Par exemple openswitch (OPX) et SONiC: OPX : https://github.com/open-switch/opx-docs/wiki SONiC : https://github.com/Azure/SONiC/wiki > Supportant un Trident II+ BCM56854 > Par exemple pour aller sur le FS N5850-48S6Q et éviter de claquer quelques > k€ en licence cumulus. https://www.fs.com/fr/products/69226.html C'est le point un peu délicat. OPX est actuellement majoritairement pour du matériel Dell: https://github.com/open-switch/opx-docs/wiki/hardware-support SONiC a une liste déjà significative de matériel supporté: https://github.com/Azure/SONiC/wiki/Supported-Devices-and-Platforms Il faudrait demander à ton(ta) commercial(e) Fiberstore si sa société soutien ou contribue à un ou plusieurs projet(s) de ce type. Bon courage. -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] SONiC
Bonjour, Suite à la présentation sympa de CRITEO à FRNOG vendredi, j'ai décidé de mettre SONiC sur un switch S4048 (Dell/Force10) pour le tester. Comme toujours avec ONIE, le changement d'OS est très simple et se fait en quelques minutes. Par contre, la plate-forme n'est pas dans la Hardware Compatibility List, et donc aucun port "front" n'est visible. Avez-vous eu vent d'un portage (même partiel) pour cet équipement ? https://github.com/Azure/SONiC/wiki/Porting-Guide Merci. -- * Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] déni de service
Bonsoir, Le 12/07/2019 à 18:34, Michel Py a écrit : > Emmanuel DECAEN a écrit : >> Avec UTRS, il est possible d'être en blackhole (trou noir), mais aussi en >> sinkhole (gouffre). >> Je pensais passer en gouffre pour analyser les attaquants potentiels >> provenant de mon réseau, voyez-vous des raisons de ne pas le faire ? > Au lieu de mettre une route vers null0, tu mets une route vers un analyseur ? C'est effectivement ce que je pensais faire. Je pourrais par exemple repérer dans notre AS des machines potentiellement utilisées pour de l'amplification ou infectées, et traiter le problème au plus vite. C'est tout bénéfice pour tout le monde, j'améliore la protection des machines chez nous et je ne participe pas au DDoS de la victime. > Aucune raison de ne pas le faire, au contraire. Je m'attendrais pas à un > miracle, ceci dit. Ca fait 2 semaines que j'ai mis UTRS, le plus que j'ai vu > c'était 70 préfixes; va probablement falloir que tu regardes le feed et que > tu envoies toi-même du trafic à un des préfixes pour vérifier que ton système > marche. J'ai également testé cette partie cet après-midi, mais c'était limité au réseau de test, il me reste à traiter de la diffusion au sein de mon AS. En gros, je dois décider si je laisse les routeurs de bordure faire tout le boulot ou si j'arrête/détourne au plus tôt dans l'ensemble du réseau. Je ne l'ai pas dit tout à l'heure mais un des aspects qui m'a impressionné, c'est la rapidité de prise en compte du système. L'ajout et le retrait d'une IP blackhole est quasiment instantané sur plusieurs des AS testés. Merci. -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] déni de service
Bonjour, Le 01/07/2019 à 15:33, Emmanuel DECAEN a écrit : > Bonjour, > > Le 28/06/2019 à 04:52, Michel Py a écrit : >> Et est-ce qu'ils souscrivent à quelque chose comme çà : >> http://www.team-cymru.com/utrs.html > Je ne sais pas, mais ça semble pas mal, je suis très intéressé par un retour > d'expérience. Je viens de faire joujou avec UTRS, le principe est plutôt sympa et simple en terme de mise en oeuvre pour un hébergeur. Cet après-midi, j'ai "trounoirisé" une IP puis j'ai simplement demandé son avis sur sa disponibilité à RIPE Atlas :-) Sur 1000 sondes réparties dans le monde entier, j'étais injoignable pour 20 d'entre elles en moyenne. Même si 2% de couverture parait assez peu, il faut aussi regarder les réseaux concernés, et là c'est encourageant: Il y a des hébergeurs, mais aussi des noms connus de Fournisseurs d'Accès Internet en Europe et en Amérique du Nord par exemple. Espérons que la communication autour d'UTRS fasse rapidement un effet boule de neige ! Pour information, à l'heure actuelle UTRS ne propose pas IPv6 et FlowSpec, il faut manifester son intérêt pour que cela soit supporté, je vais donc le faire de ce pas ;-) Avec UTRS, il est possible d'être en blackhole (trou noir), mais aussi en sinkhole (gouffre). Je pensais passer en gouffre pour analyser les attaquants potentiels provenant de mon réseau, voyez-vous des raisons de ne pas le faire ? Bon Week-End. -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Transit et déni de service
Bonjour, Le 01/07/2019 à 19:21, Alexandre BATON a écrit : >>> Et pourquoi pas BGP flowspec mais là c'est carrément du rêve pour moi. Mon >>> transit principal il a jamais entendu parler des communautés :-( >> >> J'avoue que je ne l'avais pas envisagé initialement, mais vu que BGP >> flowspec commence à être proposé, cela me tente pas mal :-). >> > BGP Flowspec me fait aussi de l’oeil mais mes transits actuels n’en font pas… > Vous avez une liste de fournisseurs de transit en France qui le propose ? Je suis également preneur d'une liste. Pour le moment, j'ai un contact avec un opérateur français le mettant en oeuvre pour son offre anti-DDoS. Je le laisse réagir ici s'il le souhaite. Merci. -- *Emmanuel DECAEN* E-Mail: e...@xsalto.com www.xsalto.com Tél: 04 92 36 60 06 Support: 04 92 36 60 07 Fax: 04 92 36 19 75 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Transit et déni de service
Bonjour, Le 28/06/2019 à 04:52, Michel Py a écrit : >> Emmanuel DECAEN a écrit : >> Comme beaucoup d'entre vous, je fais évoluer régulièrement nos liens de >> transit BGP >> (quelques 10G). Cette année, j'ai le souhait de demander à chaque opérateur >> de transit >> de prendre la charge d'un éventuel DDoS directement au niveau de son >> backbone. > Beaucoup dépend de ce que tu vois arriver comme DDOS. Si tu te prends des > DDOS térabit tous les jours, Arbor c'est très cher mais pas forcément trop > cher, çà dépend de l'épaisseur de ton portefeuille et de combien le DDOS te > coute vraiment. Si tes DDOS se font principalement sur une IP, avec les > communautés tu t'en sors très bien. Si tu as un truc qui attaque l'ensemble > de tes adresses, c'est pas glop. > Ca dépend qui est attaqué : toi, ou quelqu'un que tu héberges. > > Et beaucoup dépend aussi de ce que tes transits font déjà (communautés ? sans > une solution commerciale) > Et pourquoi pas BGP flowspec mais là c'est carrément du rêve pour moi. Mon > transit principal il a jamais entendu parler des communautés :-( J'avoue que je ne l'avais pas envisagé initialement, mais vu que BGP flowspec commence à être proposé, cela me tente pas mal :-). > Et est-ce qu'ils souscrivent à quelque chose comme çà : > http://www.team-cymru.com/utrs.html Je ne sais pas, mais ça semble pas mal, je suis très intéressé par un retour d'expérience. > C'est pas évident de faire soi-même, mais t'as 5 ingés. Achète une bouteille > de Stroh à Xavier :P Bonne idée ;-) -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Transit et déni de service
Salut Xavier, Le 27/06/2019 à 20:28, Xavier Beaudouin a écrit : >> Avez-vous des retours d'expérience sur les solutions anti-DDoS (Arbor, >> etc.) proposées par les opérateurs de transit et surtout leur efficacité >> en conditions réelles ? > Retours d'expérience: cher et autant le faire soit même avec les bonnes > communautés BGP, > tel a été le choix d'un de mes précédents jobs. Surtout quand on peux écraser > la merde > sur les routers border avec soit des ACL soit du BGP Flowspec :) Effectivement :-) Je vais laisser la porte ouverte pour une solution BGP Flowspec en plus d'une solution anti-DDoS J'ai eu quelques retours d'expérience, mais surtout plusieurs réponses commerciales en privé, voici un petit résumé des "solutions" autres qu'un équivalent Arbor : 1> prendre du gros tuyaux et nettoyer à l'entrée Le raisonnement de l'opérateur est que le prix d'une 10G est relativement raisonnable maintenant. Donc on peut nettoyer à l'entrée (ACL), et se contenter du point 2 en cas extrême (ci-dessous). 2> utiliser du BGP blackhole Quasiment tous les opérateurs semblent offrir un service de ce type. Le problème est que tu blacklistes toi même les adresses IP concernées, donc le déni de service est réussi au final. 3> Utiliser du BGP Flowspec Cette solution semble moins proposée de prime abord. Je ne sais pas encore si c'est par absence d'offre ou par méconnaissance du catalogue pour ceux qui ne l'ont pas proposé. J'aime bien le principe général, c'est très granulaire, et s'il s'applique sur tout le réseau de l'opérateur (via les PE ?), l'attaque n'entre même pas sur le réseau. Tout le monde y gagne. > En général le prix étant tellement plus élevé que prendre du tuyaux et négo > des commits > que pour cette expérience le résultat a été celui là. C'est effectivement le raisonnement de plusieurs opérateurs m'ayant contacté en privé. > > Surtout que les IX commencent a donner les moyen de null router les ips > cibles (ou mieux > shut la connection sur l'IX et attendre via flowspec / arbor / whatever que > ca se calme). Il faut que je vois avec Grenoblix Lyonix si BGP flowspec est supporté ;-) >> Ou avez-vous plutôt privilégié des solutions BGP de pure player (Qrator, >> etc.) ? > Jamais testé, elles n'existaient pas (ou débutais à l'époque). Pour certains > trucs un CDN > a été utilisé pour limiter l'impact de l'appeau a DDoS. :) J'ai eu plusieurs réponses de fournisseurs anti-DDoS utilisant BGP. Le principe est assez simple: en cas d'attaque, on coupe tous les autres transits, la totalité du trafic bascule alors sur le fournisseur anti-DDoS. Finalement, on prend des tuyaux raisonnables chez quelques transitaires classiques, et un chez le fournisseur anti-DDoS; Cerise sur le gâteau, si le fournisseur anti-DDoS est présent sur ton point d'échange favori, ta liaison avec lui ne te coute quasiment rien, tu rétribues juste le service. > Après ça fait quelques temps et donc le paysage a peut-être changé... (eg je > sais pas si > des transitaires sont BGP Flowspec compatibles par exemple). Oui, je te confirme que c'est supporté, mais je n'ai pas l'impression que c'est la grande majorité. > Ne pas oublier, certains traffic pourris viennent AUSSI des IX, et si tu as > donc des IX a > gérer, et bien les protection des transitaires peuvent être useless. Ah aussi > tu leur donne > confiance car tu dois ajouter une route de tes prefix dans leur AS... A toi > de voir jusqu'où > vas ta confiance en eux :) Aujourd'hui, la partie IX représente une faible partie de mon trafic, en cas d'attaque, je pense raisonnable de couper ;-) Je vais rester ouvert sur l'aspect DDoS, je pense que je vais prendre quelques transits 10 G en privilégiant au moins un supportant BGP flowspec. Et un prestataire anti-DDoS, qu'il soit opérateur de transit ou non. Merci de ta réponse. PS: Je ne suis pas opposé aux propositions de transit ou anti-DDoS BGP par mail privé mais pas d'appels téléphoniques SVP. -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] Transit et déni de service
Bonjour, Comme beaucoup d'entre vous, je fais évoluer régulièrement nos liens de transit BGP (quelques 10G). Cette année, j'ai le souhait de demander à chaque opérateur de transit de prendre la charge d'un éventuel DDoS directement au niveau de son backbone. Avez-vous des retours d'expérience sur les solutions anti-DDoS (Arbor, etc.) proposées par les opérateurs de transit et surtout leur efficacité en conditions réelles ? Ou avez-vous plutôt privilégié des solutions BGP de pure player (Qrator, etc.) ? Merci. -- *Emmanuel DECAEN* - e...@xsalto.com --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] iptables me rendra fou
Bonjour, Le 27/01/2019 à 10:07, Guillaume Tournat a écrit : > Ça fonctionne. Sur Debian ca me permet de conserver des noms à l’ancienne : > eth0, eth1... C'est effectivement une bonne idée pour faire du debug et isoler cet aspect dont le comportement est parfois surprenant. D'autant que ce renommage avec systemd (240-2) peut aboutir à des choses pour le moins inattendues côté réseau. Si on prend l'exemple ci-dessous, la partie L2 (VLAN 40) monte comme il faut : xgbe1.40. Malheureusement elle se trouve renommée en "rename5", et la partie L3 (IP) échoue bêtement car le nom de l'interface a changé :-( Définition de l'interface: iface xgbe1.40 inet static address 192.168.40.218/24 $ sudo ifup xgbe1.40 Cannot find device "xgbe1.40" ifup: failed to bring up xgbe1.40 $ sudo dmesg [ 56.446861] 8021q: adding VLAN 0 to HW filter on device xgbe1 [ 56.449675] rename5: renamed from xgbe1.40 $ ip link 3: xgbe1: [...] 5: rename5@xgbe1: [...] Pour les curieux, le détail est ici: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917128 Bon Week-End. -- *Emmanuel DECAEN* E-Mail: e...@xsalto.com www.xsalto.com Tél: 04 92 36 60 06 Support: 04 92 36 60 07 Fax: 04 92 36 19 75 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Téléphonie - Gigaset N720 DM Downgrade FW
Bonjour, Le 11/09/2018 à 10:41, Olivier MORFIN a écrit : > Est-ce que quelqu'un aurait une astuce pour forcer le Downgrade de firmware > sur une borne contrôleur Gigaset PRO N720DM ? Je n'ai jamais testé : Aller dans le menu "Gestion" > "Mise à jour du micrologiciel" Puis cliquer sur "Lancer retour à version précédente" Bon courage. -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] SFP+ Solid Optics vs Sandstone
Bonjour, Le 20/03/2018 à 11:25, Michel KOENIG a écrit : > Je travaille beaucoup avec des switch HPE et j'utilise exclusivement des > Gbics HPE > La concurrence propose couramment du Gbic compatible > > Quel argument pour ou contre les Gbics compatibles ? > Des expériences heureuses ou malheureuses ? Aujourd'hui aucun soucis avec les SFP+ du constructeur ou les compatibles (Intel, FS, etc.). Par contre, je commande toujours quelques exemplaires du constructeur, pour qu'en cas de problème, je puisse tester avec les SFP+ certifiés. Cela permet, entre autres, d'éviter que le support du constructeur ne soit amené à me dire : "le problème vient de l'utilisation d'un SFP+ tiers" Pour les compatibles, je demande toujours à minima une garantie commerciale d'un an, et j'achète quelques exemplaires en plus. En conclusion: expérience positive :-) -- *Emmanuel DECAEN * --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Upgrade 100FX vers 1000SX
Bonjour, Le 19/01/2018 à 10:26, David Touitou a écrit : > J'ai un petit besoin de rien du tout : supprimer des convertisseurs 100FX et > allumer deux liens sur deux bornes. > Pour de la distribution wifi dans un cas et pour une imprimante et trois > postes (PC + phone) de l'autre. > > Pas besoin de 4x10Gbps (de toutes façons le reste de l'infra ne suit pas), > même le giga n'est pas absolument nécessaire. A ce moment là, autant prendre un bête SFP 100FX (dizaines d'Euros chez FS par ex) et le tour est joué. Merci. -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [BIZ] Hébergement en Chine
Bonjour, Certains de nos clients français souhaitent héberger du site vitrine et catalogue pour leur clientèle Asiatique et particulièrement Chinoise. Nous prévoyons de partir sur de la VM ou du dédié, avec un aspect fort sur la fiabilité et disponibilité pour l'infrastructure (serveur, réseau, opérateurs). Il y a quelques temps, j'avais suivi un échange, ici même, sur les différentes possibilités afin de répondre à ce besoin. Pour résumer les échanges: - délicat et complexe d'héberger directement en Chine (licence ICP, support Chinois) - préférer un hébergement à Hong Kong plutôt qu'à Singapour ou au Japon Est-ce toujours d'actualité ? Dans les pistes à Hong Kong, il y a entre autres: AlibabaCloud (Aliyun), Outscale, Rackspace, Softlayer, Internap, Servers.com Avez-vous des prestataires à recommander/éviter ? Si vous fournissez ce type de service, vous pouvez également me contacter directement. Merci. -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] optique DWDM pour une Lambda inter DC de Lambda Paris
Bonsoir, Le 05/07/2017 à 22:20, Raphael Mazelier a écrit : > > On 05/07/2017 22:07, Michel Py wrote: >> >> Tu pourrais préciser quel genre de soucis ? J'ai pas encore acheté du >> DWDM chez eux mais je m'approvisionne régulièrement pour les optiques >> grises et les cables. >> > > Sur du consommable (du gris et du DAC) pas énormément de soucis, un > taux de panne raisonnable. Sur du gris, du DAC et de la fibre renforcée aucun retour pour le moment. Par contre sur le cuivre, je pense qu'ils ont une grosse marge de progression, je vais rester sur LCS2 et LCS3 made in France ;-) > > Sur du *wdm en revanche un festival, mauvais codage, mauvaise longueur > d'onde, sensibilité en rx foireuse, etc... Aie... Sur le DWDM, je viens d'en recevoir un petit lot actif et passif, il ne me reste plus qu'à tester. > j'en passe et des meilleures. Ceci étant ils m'ont toujours repris les > optiques, mais le temps passé en debug, allez-retour au DC, en colis > vers la chine et en discussion avec le support n'a pas compensé le > meilleur prix initial. D'après ma commerciale, leur équipe fait un tour d'Europe cet été pour discuter de ce genre de chose, et pour définir le type de stock à prévoir dans leur entrepôt Européen. J'ai décliné leur proposition de passer nous voir (fin Juillet en France), mais je pense qu'un compte comme le tien sera plus pertinent. Merci. -- *Emmanuel DECAEN* XSALTO --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Fournitures FO
Bonjour, Le 22/06/2017 à 23:11, Armel Chargé - frekences a écrit : > Je recherche un fournisseur français ( ou européen ) chez qui je peux > commander des petites fournitures FO ( jarretières, coupleurs, modules, .. ) > pour livraison en express ( 24h ). J'ai testé avec succès les produits vendus par Telenco, le commercial est très réactif, vous pouvez contacter d.sani...@telenco.com. Depuis plusieurs années maintenant, j'ai l'occasion d'utiliser les jarretières lightmax, vous pouvez contacter florian.josw...@lightmax.com. Sinon pour le J+1 sur site, il y a Rexel, mais cela a un prix. > Je commande chez FS la plupart du temps Ma commerciale m'a annoncé l'ouverture de leur nouvel entrepôt FS en Allemagne, donc en toute logique, terminés les frais de "douane" et le J+7. A bientôt. -- *Emmanuel DECAEN* E-Mail: e...@xsalto.com www.xsalto.com Tél: 04 92 36 60 06 Support: 04 92 36 60 07 Fax: 04 92 36 19 75 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Dechet eletronique
Bonjour, Le 21/06/2017 à 07:11, Lucas Viallon a écrit : > Quelqu'un sait si il y a des sociétés spécialisés qui peuvent faire la > récupération de ce type de déchet sur Paris et Lyon ? > > Qui propose par exemple que l'on puisse y déposer les déchets ou en option > viennent les chercher directement dans le DC Je pense que la société netinformatique doit pouvoir faire ce genre de chose. A ma connaissance, ils font du nettoyage de datacenter et gérent le recyclage de déchets informatiques. Vous pouvez contacter martine.masc...@netinformatique.com de ma part. A bientôt. -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Aide pour comprendre des deco ADSL
Salut Paul, Si c'est en appartement, il y a un truc à vérifier: l'ascenseur de l'immeuble. Avant l'apparition du mécanisme de correction d'erreur de la Freebox, à chaque fois que l'ascenseur bougeait: plouf perturbation ou coupure sur le flux TV (très pénible) ! Concrètement l'ascenseur étant tout le long des armoires techniques, les perturbations engendrées étaient insupportables pour l'ADSL. Le problème d'ascenseur n'a pas disparu, mais la correction d'erreurs ADSL de la box compense bien maintenant ;-) Bon courage. -- Emmanuel Le 08/03/2017 à 20:54, Paul Rolland (ポール・ロラン) a écrit : Bonjour a tous, Je suis en train de me battre avec un truc etrange : une ligne ADSL qui marche bien (par rapport a sa constit. ;) la journee, mais qui a partir de 19H00, et jusque 7H00/7H30 le lendemain, fait des pertes de synchro a raison de 5 a 10 fois par heure... Et la reconnexion se fait environ 40s apres la deconnexion, a des debits qui restent les memes a 1% ou 2% pres. Un premier contact avec l'operateur a amene a un changement de box, mais la nouvelle fait exactement la meme chose... Le truc etrange, c'est la periode sur laquelle ca se produit : soir et nuit. Est-ce que qq'un a une idee d'une piste que je pourrais suivre pour essayer de traiter ca ? La ligne en question a un debit down de 5340 Kb/s, une marge de bruit de 6.6dB et une attenuation de 51 dB - suffisant pour des erreurs tout le temps, mais la journee, ca passe... Je suis preneur de toute experience qui se rapprocherait de celle-la, c'est plutot etrange... Merci, Paul --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] - les divers routeurs BGP qui peuple le monde
Salut Jérôme, Je n'ai pas de statistique à te proposer, et je suis également preneur de l'information. Concernant les routeurs BGP, j'ai tendance à penser que si ton besoin est de l'ordre du Gigabit, tu peux envisager un Quagga ou un BIRD. L'un des avantages d'une solution logicielle est qu'en cas de panne, tu as souvent tout le matériel sur place pour dépanner (un simple serveur avec quelques ports Gigabits). Si par contre ton besoin en performance est significatif, les solutions matérielles vont peut-être mieux répondre. A bientôt ;-) -- *Emmanuel DECAEN* E-Mail: e...@xsalto.com Le 21/04/2016 12:05, Admin VGNETWORK a écrit : Bonjour la liste, Après quelques recherches infructueuse sur le net vue par google, je m'adresse à vous. Sauriez-vous ou je pourrais trouver des stats sur les routeurs BGP et leurs répartitions selon les divers marques & modèles (cisco, juniper, quagga, autre) et éventuellement un retour d'expérience sur de ces divers produits tant sur la fiabilité que la difficulté d'exploitation de tel ou tel solution. Ceci dans le but de m'éclairer sur les solutions existantes pour une mise en place d'ici la fin de l'année. Je vous remercie bien vivement ! Bonne journée @ tous Jérôme Gorgibus -- --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] Ports 10 Gbps
Bonjour, Le 21/04/2016 12:55, Edouard Chamillard a écrit : pour les nics j'ai tendance a fonctionner sur le mode "fibre jusqu'au rack, twinax a l'interieur" pour le nouveau matériel. Je me permets de rebondir sur cette réponse. Aujourd'hui, la connexion 10G/40G entre baies se fait essentiellement en fibre, en particulier pour des raisons de distance à couvrir. Par contre au niveau d'une même baie, la connexion 10G entre les ports des switchs et les cartes des serveurs sont en Twinax ou en Fibre. Avec le brassage fréquent dans chaque baie, j'ai l'impression (peut-être à tort) que la fibre risque de casser plus facilement que du Twinax. Avez-vous un retour d'expérience sur le choix Twinax vs Fibre pour de la connexion de serveurs en 10G sur les switchs de la baie ? Merci. -- *Emmanuel DECAEN* E-Mail: e...@xsalto.com www.xsalto.com Tél: 04 92 36 60 06 Support: 04 92 36 60 07 Fax: 04 92 36 19 75 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Philippe Bourcier, la fibre au bureau
Bonjour, Le 18/08/2014 22:02, Vincent Bernat a écrit : Le 18 août 2014 18:55 GMT, Thierry Martin (Europe) thierry.mar...@dimensiondata.com : 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) ?? Pour 30$, il y a des cartes avec deux SFP sur chipset Intel 82575EB (donc pas du bas de gamme). 30$ de plus pour le SFP. À l'unité. Effectivement, à ce prix là... c'est accessible :-) Le 18/08/2014 20:55, thierry.mar...@dimensiondata.com a écrit : et maintenant: - toujours plus chère, si on fais le VRAI calcul (connectique + tests en plus ) - les précâblages optiques sont-ils réexploitables ?? NON , ils sont en OM1 et limité à 10/100Mb Sur une offre telle que celle de Legrand, il s'agit d'OM3 (pas d'OM1). http://www.legrand.fr/professionnels/loffre-fibre-optique-ftto-fiber-desk_3633.html 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. Philippe fait très souvent avancer les choses, cette agressivité inutile est, en outre, injustifiée. Merci. -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [JOBS] CDI à Grenoble - Administrateur système et réseau
Bonjour, La société XSALTO située en région Grenobloise recrute en CDI un administrateur système et réseau: Administrateur système et réseau Type de contrat : CDI Lieu : Grenoble Niveau d'expérience : Expérimenté Salaire: à partir de 30 kEuros Date de démarrage souhaitée : dès que possible Intégré dans l'équipe hébergement et exploitation. Participe à l'exploitation et à l'administration d'un centre de plus de 200 serveurs. Astreintes non présencielles avec interventions sur site, une semaine sur 3 ou sur 4. Sous la responsabilité du directeur technique de l'activité. Les tâches incluent : Installation, exploitation et administration des routeurs (en particulier: BGP et OSPF) des firewalls réseaux, systèmes et applicatifs de solutions de virtualisation vmware et xen de serveurs linux (90%), windows des équipements réseaux, des serveurs de sauvegarde Développement (bash, perl, php...) de scripts systèmes d'extensions du portail de gestion de comptes client Contacts téléphoniques et mail support des clients internes et externes (en français et en anglais) relation avec les fournisseurs et opérateurs (en français et en anglais) Profil Passionné de système et de réseau Parle un anglais technique correct Lit l'anglais technique couramment Très bonne connaissance pratique en systèmes et réseaux Très forte capacité à travailler en équipe, écoute Rigueur dans le suivi et la rédaction des procédures Capacité à assister téléphoniquement des clients Pour postuler: person...@xsalto.com N'hésitez pas à me contacter en privé pour toute question ou précision. Merci. -- *Emmanuel DECAEN* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Le bal est ouvert : c'est parti pour les offres de rachat d'adresses IP
Bonjour, Le 24/10/2012 14:15, Laurent CARON a écrit : On 24/10/2012 14:05, Baptiste Malguy wrote: Depuis ce matin, déjà deux méls (un d'origine francophone, l'autre anglophone) pour nous racheter des adresses IPv4. J'ose à peine imaginer chez les copains. A vos calculettes ;-) Hello, Toi aussi tu as reçu un mail de Vincent.P qui offre 5€/IPv4 ? ;) Oui, déjà en trois exemplaires... Merci. -- *Emmanuel DECAEN* - XSALTO --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Salle informatique et diffusion du poids
Bonjour, A 350 Kg / M², pour 20 M², vous avez un potentiel de 7 tonnes, vous devriez pouvoir mettre 2 baies ;-) Concrètement, si vous posez un plancher technique, il existe une solution assez simple et peu couteuse. Imaginons que votre salle fasse 4M x 5M: - vous posez 7 IPN de longueur 5M espacés de 0,6M dans le sens de largeur - vous posez les vérins de votre plancher technique uniquement sur les IPN - vous répartissez ainsi votre charge sur l'ensemble de la surface En simplifiant beaucoup les calculs: Vous posez chaque baie sur deux IPN différents, vous répartissez votre charge sur 6 M² (2 tonnes). Il reste à tenir compte du poids des IPN, du plancher technique, et des baies mais cela vous laisse quand même un forte marge de manœuvre. Si cela vous intéresse, je dois avoir conservé l'étude d'un ingénieur structure pour une salle de 44 M², avec la répartition et l'implantation de 7 baies de 900 Kg. (*) IPN: http://fr.wikipedia.org/wiki/Poutrelle_I_%C3%A0_Profil_Normal Bon courage. -- Emmanuel DECAEN Le 11/10/2011 17:26, David B. a écrit : Bonjour à tous, Je rebondis sur le sujet d'Emmanuel Lebois ([FRnOG] Retour experience clim de toit de baie ou call corridor?) . Je suis aussi en train de créer une petite salle informatique, mais j'ai des contraintes de poids très forte (max 350 Kg du m²). Par contre, je ne manque pas de place, la salle fait 20 m². J'ai aussi résolu le soucis de clim (salle au dernier étage, modèle de clim sur le toit). Reste le soucis du poids des machines. Je dois caser au moins 2 baies. Du coup, j'ai prévu de prendre des baies sans porte. Je dois arriver à 100 Kg par baie 42U. Puis les onduleurs, environs 40 Kg x 2. Soit un poids total d'une baie vide de 180 Kg, il ne reste plus grand chose. Du coup, je vais surement mettre 4 baies mais moins les remplir. Ne vous inquietez pas, ma question arrive. :-) Une baie 42U, cela fait 1m x 0.6 m, soit 0.6 m² environs. 0.6 x 350 = 210 Kg ! :( Auriez-vous un retour d'expérience sur une sorte d'estrade ou de plaque sur laquelle je pourrais mettre ma baie afin de mieux répatir le poids ? Par exemple une plaque de 1m² sur laquelle je pose la baie. Après oui, il peut rester le cas d'un plancher technique, mais est-ce que ce dernier va bien répartir le poids ? J'ai surtout peur qu'il le concentre sur des poids précis en fait. Merci à tous pour votre aide et bonne fin de journée. David. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
