Re: [TECH] [FRnOG] Re: Un CDN Down ?
On 10/06/2021 15:41, Damien Wetzel wrote: Ton systeme ne fonctionne que si tu mets en cache que les sous domaines de ta page (pas le www) et neccessite un developement agile du site (ils sont souvent figés et il est difficile d'en changer l'archi) Disons que si tu as la problèmatique du multi cdn tu dois être assez gros pour avoir une équipe de dev capable de réaliser ceci. Après globalement ce que tu mets en cache c'est quand meme souvent tes assets et ou des choses très statiques qui ne sont pas accédé directement. Enfin tu peux tenter de CDNiser tout ton site mais c'est assez casse gueule, qu'on se rappelle la blague sur l'invalidation de cache. D'autres part, j'ai l'impression que la plupart des resolveurs operateurs acceptent et obeissent à des ttl relativement courts contrairement à une époque ancienne. La solution DNS meme si elle n'est pas parfaite me parait la seule utilisable à l'heure actuelle. Je suis d'accord qu'avoir un ou plusieurs niveaux d'indirections niveau DNS avec des ttl(s) courts (et globalement ca marche meme si moche théoriquement) est une solution simple. La question après c'est à qui tu confie ta gestion de ton DNS. Les services types route53 sont vraiment pratique mais ont souffert leur lots d'indisponibilités. Tu peux aussi avoir un mécanisme qui controle différente API de différents fournisseur DNS en effet. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [TECH] [FRnOG] Re: Un CDN Down ?
On 09/06/2021 14:51, Renaud Chaput wrote: a m'ammène à la question du multi-CDN, est ce que sa complexité se justifie pour palier à des problemes comme celui rencontré hier qui sont quand meme relativement trés rares ? Cela dépend de ton buisness comme toujours. Le multi CDN n'est pas nécessairement complexe et tu n'as pas besoin d'un intermédiaire pour le faire. Cela dépend evidement de ce que tu caches mais cela ne me parait pas déconnant d'avoir une brique interne qui construit les URLs de ce que tu as à cacher/servir via ton CDN. On le faisait dans un previous job et cela avait beaucoup d'avantage, redondance de CDN, controle des couts aussi. Et tout cela sans intervention/magie DNS. Tu peux meme cacher le resultat avec un ttl assez court pour lisser les gros burst et protéger tes origines. Cela ne te protégera pas complétement mais cela limitera beaucoup la casse. Sinon en beaucoup plus simple tu utilise un DNS type route53 et tu fais du weighted DNS sur les x domains de tes x CDNs. Alors évidement dans ce cas tu déportes le spof chez ton fournisseur de DNS. Est ce que avoir une config de secours sur un autre CDN + un DNS configurable rapidement avec des TTL courrs ~1min a un sens ? Voir ci dessus, perso je pense que cela peut valoir le coup, mais tout dépend de ton buisness. Le gros problème du multi-CDN c’est la configuration du-dit CDN. Si tu ne t’en sers que pour du cache simple de fichiers statiques, pourquoi pas, mais si tu fais des choses plus complexes (réécriture de requêtes, sécurité, optimisation d’images, routage dynamique, intelligence at the edge) ça devient beaucoup plus compliqué. J'ai un avis assez tranché sur le fait qu'on ne devrait pas mettre d'intelligence spécifique à un fournissseur CDN (ou autre d'ailleurs) pour des raisons de risque de couplage. Sinon quand tu veux bouger pour x raisons (souvent financière) tu es un petit peu dans le mal. Et vu que la grosse force de Fastly c’est de pouvoir faire un peu ce que tu veux en terme de config, ça me parait vraiment complexe de le redonder. Et ensuite, quelle est la probabilité que ta brique qui gère la redondance cause à son tour une panne, est-ce plus ou moins élevé que la proba que Fastly (ou autre) tombe ? Est-ce que tu n’introduis pas un SPOF via ton outil de multi-CDN ? Bref, sujet complexe et pas évident quand on commence à considérer tous les aspects. Assurément mais passionnant. -- Raphael --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] [BGP] Traffic arrivant sur un seul lien au lieu de deux
On 09/06/2021 18:51, Michel Py via frnog wrote: Je confirme SFR pour les deux (vu de Verizon). Vu que tu prepends 6 fois ton AS pour le 225, il serait logique en effet que le chemin par Cogent soit préféré, mais non. Par contre, en venant de Comcast, ça passe par Cogent. 6 fois carrement ? de souvenir au dela de 3 tout le monde normalise. Et encore une fois après ton transitaire il réanonce bien comme il veut. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH][BGP] Traffic arrivant sur un seul lien au lieu de deux
Oui ca ca doit marcher, parce si que tes upstreams changent tes annonces la c'est vraiment abusé. On 09/06/2021 18:41, David Ponzone wrote: Certes. Peut-être plus « fiable » d’annoncer le /23 aux 2, et un /24 à chacun, sans prepend. Le 9 juin 2021 à 18:32, Raphael Mazelier a écrit : De toute manière on ne répettera jamais assez qu'influencer le trafic in n'est pas une science exacte, tes upstreams pouvant précisement faire ce qu'ils veulent. On 09/06/2021 18:21, David Ponzone wrote: J’ai pas encore regardé en détail, mais déjà avoir comme upstream: -un Tier1 (même si certains considèrent que Cogent n’est pas un T1) -un Tier2, qui comme toi a ce Tier1 comme upstream c’est se mettre dans une situation un peu compliquée et que tu maitrises pas forcément. Moi de mon côté, je vois: 80.77.224.0/24 par SFR seulement, sans prepend 80.77.225.0/24 par COGENT (sans prepend) et par SFR (avec prepend) Donc c’est bon. Qu’est-ce qui te fait penser qu’il y a un problème ? Zero traffic sur le lien Cogent ? --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH][BGP] Traffic arrivant sur un seul lien au lieu de deux
De toute manière on ne répettera jamais assez qu'influencer le trafic in n'est pas une science exacte, tes upstreams pouvant précisement faire ce qu'ils veulent. On 09/06/2021 18:21, David Ponzone wrote: J’ai pas encore regardé en détail, mais déjà avoir comme upstream: -un Tier1 (même si certains considèrent que Cogent n’est pas un T1) -un Tier2, qui comme toi a ce Tier1 comme upstream c’est se mettre dans une situation un peu compliquée et que tu maitrises pas forcément. Moi de mon côté, je vois: 80.77.224.0/24 par SFR seulement, sans prepend 80.77.225.0/24 par COGENT (sans prepend) et par SFR (avec prepend) Donc c’est bon. Qu’est-ce qui te fait penser qu’il y a un problème ? Zero traffic sur le lien Cogent ? --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Technos pour du lan bouclé
Salut Pierre, Moi j'aime bien celle de l'oob qui boucle et qui mets par terre toute la prod :) Dans une autre vie j'ai pas mal d'anectode avec le VTP, ou avec du redback aussi... En effet ca serait intérressant d'archiver toutes nos expériences de prod un peu touchy/marrante et pas que de le réseau d'ailleurs, j'ai un paquets d'histoire coté systeme/stockage aussi. ++ On 04/06/2021 17:46, Pierre LANCASTRE wrote: Roh j en ai pas mal des histoires comme ça, et des récentes sur d'autres matos, mais même si c' est Vendredi, on va éviter de trop en dire. Petite question : il existerait un forum / blog type "corbeau du réseau" où seraient tracés les bugs les plus sympas que les gens aient pu voir ? --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Recherche fibre noire ou lambda 10G France-IX <=> Equinix PA4
On 20/05/2021 16:51, Radu-Adrian Feurdean wrote: Ca depend de MUX. Il y en a avec des filtres, il y en a sans. Ca dépend, ca dépasse :) J'imagine tout de meme que chez lambda-paris (sipartech) on a des mux qui filtrent. De souvenirs d'ailleurs ils testent bien ton optiques et ne te laissent pas trop le choix (du ZR quoi, pour pouvoir se permettre du re-reroutage le cas écheant) -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Boitier Multi-ISP
- A cause de l’option manquante pour ajouter une route statique sur la Livebox en mousse ? Tu t’en fous, tu fais du NAT sur ton routeur intermédiaire, et y a un autre NAT sur le CPE opérateur. Le double-NAT a jamais tué personne. Tu peux aussi virer la Livebox…. C'est ce que j'allais dire. Le moins d'equipement de ton ISP tu as le mieux tu te portes en général. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Looking for Data Centers Near Orléans
Brittany => Rennes => Reims => Orleans ... You may want to try Paris :-) it's getting closer. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Panne SIP Free (Free et Centile)
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). bref bon debug. -- Raphael Mazelier On 22/04/2021 11:02, Emmanuel DECAEN wrote: 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. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Panne Free sur des centaines de DSLAM ?
Les dslams font grêve suite au départ de Rani ? /me => [] -- Raphael Mazelier On 21/04/2021 09:55, jehan Procaccia wrote: bonjour, apparement il y aurai une panne generalisée de centaines de DSLAM [1] Free dans l'oeust/sud-ouest !? cf https://www.free-reseau.fr/ *[1] 361 DSLAMs ne sont pas joignables actuellement* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Bitream -> Bras alternatives a JunCisco?
On 30/03/2021 17:01, David Ponzone wrote: Go Krotik! C’est du pppoe sur un l2 de bout en bout, ou dans du L2TP ? Il y a pas des solutions soft sous nux ou bsq qui pourraient faire le taf ? -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] OVH : SBG-2 en feu
On 10/03/2021 10:00, Wallace wrote: Vous avez souvenir d'autres incidents du même type en France ou EU? A part des mini départs lors de maintenances maitrisés rapidement avec ou sans impact électrique, je n'ai pas connaissance d'autres cas. Bonjour, et bien sur toutes mes pensées aux OPs Ovh et autres sociétés qui sont impactés par ce sinistre. Je me posais la même question si on avait des cas similaires récents (ou moins) en France. Le seul truc dont je me rappelle qui ressemble vaguement à cela c'est l'incendie partiel de NetCenter CBV en 2004(5?). Un moteur de climatisation avait pris feu, ce qui avait eu la double conséquence de 1) faire prendre feu au batiment 2) couper la clim sur une partie du DC. L'incendie en lui meme avait été promptement éteint mais la clim avait du mettre une 20aine d'heure à revenir. Résultat des courses il y avait eu beaucoup de casse dans les salles. A l'époque ma société s'en était bien sortie car nous avions pu accéder à notre salle, tout éteindre, et ouvrir les fénetres (sic). Mais d'autres n'avaient pas eu cette chance, et a priori il y avait eu beaucoup de matériel HS. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Convertisseur Fibre 1G LC - Cuivre en DC
N'importe quel média conv fera l'affaire. Niveau fiabilité ces trucs sont tellement simple qu'ils marchent. J'ai en mis en prod des dizaines et n'ai jamais eu à m'en plaindre ; type : https://www.fs.com/c/media-converters-extenders-1037 vu le prix tu prends un spare et voilà :) -- Raphael Mazelier On 04/03/2021 09:34, Fabien H wrote: Bonjour, je suis à la recherche d'un convertisseur fiable pour brancher une porte de collecte monomode LC 1G sur un routeur CISCO avec port Cuivre 1G. Je ne peux pas utiliser nos SW CISCO pour faire la conversion pour des raisons d'isolation des VLAN qui y transitent. Avez-vous des références très fiables (uptime et non buggé) et pas trop trop cher ? Alim 220V Merci, Fabien --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Comment AWS implémentent-tils 169.254.169.254?
On 23/02/2021 10:05, Philippe Bourcier wrote: Cela dit, tu peux aussi faire un réseau entièrement static en adressage APIPA... comme si c'était une autre plage d'IPs privées (192.168/16, 10/8, etc.) et c'est ce que semble faire AWS. Pour répondre à la question initiale : comment AWS gére 169.254.169.254 (et quelques autres) ? Sur ton instance AWS en général tu vois une route du style : |169.254.0.0/16 dev INT_PRIV_VPC scope link metric 1000 | Donc si tu interroge donc 169.254.169.254 la trame va partir sur le réseau local et un équipement réseau va l'intercepter pour la rediriger vers un serveur de metadata proche. On peut dire que l'IP en question est partout et nulle part à la fois (sur aucun équipement/serveur) :p D'une manière générale AWS fait du custom sur son réseau; ca serait très intérressant de savoir comment ils gérent toute cette infra at scale mais ce n'est pas très publique. (il y a bien quelque confs, papiers mais cela reste parcelaire) -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] TF1.....
On 18/02/2021 14:12, David Ponzone wrote: Pas de JT de 13h sur TF1, la cause serait une cyber-attaque (ransomware ou autre). Quelqu’un (de E-TF1 peut-être) aurait plus d’infos ? etf1 c'est très séparé du "broadcast" tf1. De toute facon même si quelqu'un savait quelque chose ce serait étonnant qu'il commente cela publiquement, car pour connaitre un petit peu la boite je me doute que cela a du être une décision difficile. Attendons donc le communiqué officiel. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Notre meilleur argument pour vendre du FTTO
Tain le cauchemard… C'est fou, et désespérant… On voit aussi un peu de positif avec des opérateurs qui forcent les recâblages et qui semblent avoir compris un petit peu l'ampleur du problème. Mais dans l'ensemble cela ne m’étonne guère ; déjà à l’époque qu'est ce que j'ai pu pester contre le câblage fait en datacenter de certaines de mes précédentes compagnies dans les telcos (avec de belles exceptions, coucou max, coucou etf1). Ce que je trouve particulièrement désolant c'est que les personnes qui réalisent du mauvais câblage n'ont aucun respect pour les personnes qui viennent après eux. C'est un manque de professionnalisme et de l’égoïsme. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] 1.1.1.1 sur France-IX
C'est réparé depuis 3215 et ça passe bien par 5510. Coïncidence ? je ne crois pas. -- Raphael Mazelier On 13/01/2021 18:27, Philippe ASTIER via frnog wrote: Yep ! Réactifs, CloudFlare :) philippe@Mini-M1 Application Support % host yahoo.fr <http://yahoo.fr> 1.1.1.1 Using domain server: Name: 1.1.1.1 Address: 1.1.1.1#53 Aliases: yahoo.fr <http://yahoo.fr> has address 74.6.136.150 yahoo.fr <http://yahoo.fr> has address 124.108.115.100 yahoo.fr <http://yahoo.fr> has address 212.82.100.150 yahoo.fr <http://yahoo.fr> has address 106.10.248.150 yahoo.fr <http://yahoo.fr> has address 98.136.103.23 yahoo.fr <http://yahoo.fr> mail is handled by 10 mx-eu.mail.am0.yahoodns.net <http://mx-eu.mail.am0.yahoodns.net>. Le 13 janv. 2021 à 18:24, Clement Cavadore <mailto:clem...@cavadore.net>> a écrit : Probleme réglé :) Host Loss% Snt Last Avg Best Wrst StDev (...) 2. hundredgige0-8-0-2.auvtr5.auberv 0.0% 2 0.9 0.9 0.9 0.9 0.0 3. hundredgige0-1-0-10.partr2.saint 0.0% 2 0.9 0.9 0.9 0.9 0.0 4. cloudflare-18.gw.opentransit.net <http://cloudflare-18.gw.opentransit.net> 0.0% 2 1.8 1.6 1.4 1.8 0.2 5. one.one.one.one 0.0% 1 1.2 1.2 1.2 1.2 0.0 Le mercredi 13 janvier 2021 à 09:06 -0800, Louis Poinsignon a écrit : On a mis à jour Cloudflare status: pour suivre l'incident en cours https://www.cloudflarestatus.com/incidents/t2vcfxt28rwn <https://www.cloudflarestatus.com/incidents/t2vcfxt28rwn> On Wed, Jan 13, 2021 at 8:54 AM Jérôme Fleury wrote: Merci pour le signalement. C'est en cours d'investigation chez Cloudflare. En ce qui concerne l'annonce sur les RS, je confirme que Cloudflare n'annonce pas 1.1.1.0/24 et 1.0.0.0/24 sur les route-servers de FranceIX (et aucun route-server en general) On Wed, Jan 13, 2021 at 5:48 PM Clement Cavadore < clem...@cavadore.net> wrote: Message passé à qui de droit pour 1.1.1.1, tant coté Cloudflare, que OTI. (Nb: 1.0.0.1 fonctionne depuis OTI) Le mercredi 13 janvier 2021 à 17:30 +0100, Romain a écrit : Si, ça dépend comment tu tests. Ca a été corrigé via le firmware il y a longtemps, même si un traceroute par défaut le route en local sur la livebox. Un traceroute en UDP sur le port 53 montre bien un routage correct vers l'extérieur. Le mer. 13 janv. 2021 à 17:17, Paul Caranton < caranton.p...@gmail.com a écrit : 1.1.1.1 ne fonctionne pas derrière une Livebox (pas la 4 en tout cas). Paul AS208261 Le 13 janv. 2021 à 17:16, à 17:16, Raphael Mazelier < r...@futomaki.net> a écrit: Je ne sais pas mais chez moi (cnx orange) 1.1.1.1 était pétave aussi. On 13/01/2021 17:03, David Ponzone wrote: Ami.e.s France-IXien.ne.s, Est-ce normal que Cloudflare n’annonce pas le 1.1.1.0/24 aux RS de France-IX ? Merci --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ <http://www.frnog.org/> --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] 1.1.1.1 sur France-IX
On 13/01/2021 18:00, David Ponzone wrote: Je me demande si c’est pas une coïncidence. Un dev qui aurait utilisé 1.1.1.1 à une époque où c’était sans impact. Sinon, ils intercepteraient 8.8.8.8 aussi non ? Pour la livebox je ne sais pas. Je pensais plutôt à la SFR box qui fait de l'interception magique de dns (quel qu'il soit), en filtrant par exemple les rfc1918. A quoi ça sert ? -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] 1.1.1.1 sur France-IX
On 13/01/2021 17:18, Stephane Bortzmeyer wrote: Il doit s'agir de deux choses différentes. L'absence sur les serveurs de route ne signifie pas injoignabilité (le transit est là) et certaines Livebox ont un microcode qui fait des choses pas belles avec 1.1.1.1. Parce que j'ai une tête à garder la livebox ? :) -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] 1.1.1.1 sur France-IX
Je ne sais pas mais chez moi (cnx orange) 1.1.1.1 était pétave aussi. On 13/01/2021 17:03, David Ponzone wrote: Ami.e.s France-IXien.ne.s, Est-ce normal que Cloudflare n’annonce pas le 1.1.1.0/24 aux RS de France-IX ? Merci --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Petite question tech concernant l'accès à la TV depuis Free
On 08/01/2021 22:27, Pierre LANCASTRE wrote: Récemment retourne chez Free en Freebox PoP en fibre (négo a 5G/700M) je suis très loin de saturer le downstream et j'ai eu pas mal de problèmes de lag/glitch de son, signe de perte de paquets. Mais pas sur toutes les chaînes, c était surtout TF1 et BFM TV pendant les Peak hours. Sachant que je suis en filaire partout et qu avec ma box orange j' avais 0 souci, je pense que ça vient de plus haut :) peut être saturation entre leur backbone et l olt de ma zone, ou plus haut? Il y a pas mal de Root cause possibles. En tout cas, ce soir tout va bien, peut être qu ils ont lu le thread ^^ My 2 cents Sur le flux tnt ? bah c'était peut être une saturation généralisée sur le réseau de distribution des flux tv coté Free ? (je rappelle flux live "tnt" ça reste sur les infras des opérateurs, et heureusement j'ai envie de dire) -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Petite question tech concernant l'accès à la TV depuis Free
On 07/01/2021 20:26, Vincent Bernat wrote: J'ai aussi ça chez mes parents. Ils sont en Freebox v4 avec le boitier TV derrière le CPL. Pour moi, c'est la Freebox qui ne sait plus gérer correctement la QoS car ça arrive plutôt quand les petits-enfants sont dans le coin. Pas tenté le support. Piste intéressante mais dans le cas de David il semble dire qu'il n'y a pas spécifiquement d’activé sur la box au même moment (après question à la noix, il y aurait t'il le freewifi d'activé ?) -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] SFR NUMERICABLE, c'est déjà trolldi ?
On 08/01/2021 08:01, Benoit SERRA wrote: En aparté, abonné à SFR-NUMERICABLE depuis presque 3 ans (c'est ça ou l'accès adsl à 2mbps) j'ai constaté que leur box, en mode Routeur, ne donne pas le débit. Mais passée en mode bridge avec un vrai routeur derrière, j'ai le débit quasi nominal en 1Gbps Dl et 50 Mbps UL. Yes en réduisant la box au minimum vital cela fonctionne (Box SFR Zive). Il faut passer en mode "bridge" et tout désactiver et c'est ok. De base la box gère très très mal le nat. A noter tout de même que la box fait quand même de l'interception DNS, bridge ou pas ce qui peut être pénible. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Règles de Nommage des zones DNS privées
On 07/01/2021 20:59, Philippe Bourcier wrote: Enfin, j'aurais tendance à prendre un mondomaine.tld dédié à l'IT, qui n'a pas forcément de lien avec le nom de la boîte, ce qui permet d'éviter une migration AD en cas de revente/renommage de la boîte... +1000 on ne sait jamais si une société va être racheté ou non, alors le domaine interne sans rapport avec le nom de la société c'est souvent salvateur. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Petite question tech concernant l'accès à la TV depuis Free
On 07/01/2021 17:14, David Ponzone wrote: C'est sûr, mais 13h30, même en ce moment, j’avais du mal à imaginer que ça soit une crête du même ordre que celle du soir. Ah tu as le problème à 15h30 ? a la fois sur le flux "tnt" et en OTT ? Very strange. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Petite question tech concernant l'accès à la TV depuis Free
On 07/01/2021 17:07, David Ponzone wrote: Tout est possible, je dois refaire des tests, mais au même moment, je n’avais aucun problème depuis une fibre Bouygues. Sur les peak hours ça m’étonnerait guère que divers trucs qui n'ont aucun rapport soient saturés. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Petite question tech concernant l'accès à la TV depuis Free
On 07/01/2021 16:58, David Ponzone wrote: Ben non puisque ça déconne aussi en OTT sur le web de France2 ou Arte. Simple coincidence horaires ? -- --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Petite question tech concernant l'accès à la TV depuis Free
On 07/01/2021 16:11, David Ponzone wrote: En streaming, le splitter est le serveur qui reçoit un flux live et le diffuse vers X clients. Enfin, ça s’appelait comme ça avant. Mais d’après ce que tu me dis, les chaines sont reçues par le FAI avec une techno de broadcasting dédiée (IP ou non), probablement via un TDF ou Globecast, et donc, plus de point commun, sauf le réseau interne Free. En général pour les grosses chaînes et FAI c'est en direct de gré à gré, avec une techno X de broadcast (je ne me rappelle même plus, peut être du SDI over IP, enfin en tout cas un flux full patate niveau qualité). Pour les plus petits broadcaster, ou pour le backup ca peut passer par des réseaux intermédiaires style TDF par exemple, mais cela reste des réseaux privés. Un joyeux bazar de fibre bien concentré à TH2 par ailleurs. J’ai oublié de dire qu’au même moment, j’ai fait un nperf à 12Mbps descendant, 500Kbps montant, ce qui est à peu près la capa de l’ADSL, donc j’ai pas de raison de penser que le réseau de Free va mal (fast.com <http://fast.com> et openspeedtest.net <http://openspeedtest.net> m’ont par contre sorti un résultat délirant, du genre 12Mbps entrants et 120Mbps sortants, ça arrive de plus en plus souvent). Bref, pas assez de tests pour comprendre, je vais essayer d’en faire plus. C'est peut être le réseau/infra de streaming interne de Free qui est saturé ? -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Petite question tech concernant l'accès à la TV depuis Free
On 07/01/2021 16:01, David Ponzone wrote: Il y a quand même un point commun si le flux live de France2 arrive en IPv4 vers les splitters de Free. France2——IPv4——> Free Splitter——IPvx——>abonné France2——IPv4———>abonné Free Dans les 2 cas, le transit IPv4 de Free est impliqué mais j’ai du mal à croire qu’ils saturent vers France2 et Arte etc….. Ou alors ils ont un problème sur un IX depuis quelques jours. Je ne t'ai pas suivi : qu'est ce que tu appelles les splitters free ? Les flux live des chaînes qui sont redistribués par les FAI sont sur des réseaux privés bien séparés (et qui ne sont pas saturés, enfin on peut/doit l’espérer, et aussi c'est un débit stable et fixe dans le temps ) . -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Règles de Nommage des zones DNS privées
On 07/01/2021 15:25, Alain Bieuzent wrote: Bonjour la liste, Existe t’il quelque part des règles ou recommandations de nommages des zones et sous zones DNS. Par ex , quels est le plus propre entre : printer.private.fr.mondomaine.tld ou private.printer.fr.mondomaine.tld ou fr.printer.private.mondomaine.tld etc … Bonne question. A priori la seule vrai règle est d'utiliser un vrai domaine publique et non whatever.priv ou whatever.internal. Je ne vois pas de problème à utiliser priv.corp.com par exemple. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Petite question tech concernant l'accès à la TV depuis Free
Hello je vais essayer de te répondre car j'étais dans le milieu il n'y a pas si longtemps. On 07/01/2021 14:21, David Ponzone wrote: J’essaie de diagnostiquer un souci chez un membre de ma famille abonné Free et je me pose des questions. Depuis quelques temps, les chaines de TV (au moins la TNT) sur la Freebox (en CPL) freezent et pixelisent à certaines heures (JT 13h, JT 20h). Depuis un PC en WIFI, même problème sur le web direct de France2 ou Arte (en IPV4 à priori), mais Netflix est nickel (en IPv6 probablement). Je me demande donc où est le dénominateur commun: est-ce que quand je vais sur le web direct de France2 ou Arte, je suis renvoyé vers un serveur de streaming chez Free (auquel cas il a du mal en ce moment aux heures de pointe), ou est-ce que quand je regarde une chaine TNT sur la Freebox TV, je suis renvoyé vers les serveurs de la chaîne demandée (auquel cas c’est plutôt le transit IPv4 de Free qui aurait un souci mais ça me semble un peu gros). Connaissant la logique économique d’un FAI, je suppose qu’ils font le maximum pour que ça reste on-net donc je penche pour le cas 1. Ou il y a un dénominateur commun que j’ai raté…. Il faut bien distinguer deux cas : - le live et replay depuis ta freebox (et/ou player free) tu tapes sur les serveurs/archi free. Dans les deux cas le contenu est ingéré depuis chaque broadcaster vers free. Pour le live c'est fait via des DFs dédiés, en multicast . Ensuite Free en fait ce qu'il veut et en l’occurrence le diffuse via son infra que je connais mal, mais qui globalement ré-encode le flux recu, le mets sur ses serveurs et le diffuse (je crois que ca utilise du multicast aussi, et que c'est un peu régionalisé). Pour les replays, les broadcasters envoient les replays via X méthodes (ftp parfois :) ) puis pareillement Free le ré-encode et les mets sur ses serveurs puis les diffuse de la manière qu'il lui plaît (pour le coup c'est sans doute un simple CDN interne). - le live et replay OTT, donc quand tu vas sur le site de chaque broadcaster. Dans ce cas tu passes via le grand internet et tu tapes sur les serveurs de diffusions des chaînes qui sont soit délivrés via des CDNs publiques ou via des CDNs privée (certains broadcaster ont des PNIs avec Free). Pas de magie ici. Il n'y a donc pas vraiment de point commun, à part qu'au départ tu passes par le réseau interne Free. Si dans les deux cas tu as l'impression que c'est saturé au même horaires c'est soit une coïncidence, soit que le réseau interne de ta plaque Free est saturé à ce moment, mais c'est étrange que Netflix passe au même moment. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Revendeur câble RJ45 au métre
Ah tu as un lien pour ca ? On 04/01/2021 12:50, Xavier Beaudouin wrote: Il y a des connecteurs SC/UPC (ou même SC/APC) qui sont a visser qui font assez bien le travail. Oui c'est moins chouppi qu'un beau connecteur bien fait, mais ça marche. - Mail original - De: "Raphael Mazelier" À: "frnog" Envoyé: Lundi 4 Janvier 2021 12:20:43 Objet: Re: [FRnOG] [BIZ] Revendeur câble RJ45 au métre Sans pousser à la consommation (à la maison je reste au cuivre et au wifi), çà devient plus que raisonnable : Switch 8 ports GE plus 2 ports SFP+ 10G : cent balles https://mikrotik.com/product/css610_8g_2s_in SFP+ 10G : 16 balles https://www.fs.com/fr/products/74668.html?attribute=106 Jarretière 10G fibre 2m : 4 balles Plus long : 1 € le mètre https://www.fs.com/fr/products/40220.html Pas de problème coté équipement, SFP. C'est plus que je ne peux pas faire passer une jarretière dans mes fourreaux (encore que je pourrais essayer) et que je n'ai pas le matos pour faire les connecteurs. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Revendeur câble RJ45 au métre
Sans pousser à la consommation (à la maison je reste au cuivre et au wifi), çà devient plus que raisonnable : Switch 8 ports GE plus 2 ports SFP+ 10G : cent balles https://mikrotik.com/product/css610_8g_2s_in SFP+ 10G : 16 balles https://www.fs.com/fr/products/74668.html?attribute=106 Jarretière 10G fibre 2m : 4 balles Plus long : 1 € le mètre https://www.fs.com/fr/products/40220.html Pas de problème coté équipement, SFP. C'est plus que je ne peux pas faire passer une jarretière dans mes fourreaux (encore que je pourrais essayer) et que je n'ai pas le matos pour faire les connecteurs. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Revendeur câble RJ45 au métre
On 04/01/2021 11:51, Daniel Caillibaud wrote: Tant qu'on cause câbles, est-ce que la fibre résiste mieux dans la durée en extérieur ? Je dois tirer des câbles elec dans un fourreau enterré pour alimenter une maison de jardin, et je voulais y passer aussi un câble réseau, mais on m'a dit (sur une ml, me rappelle plus où) que c'était pas très résistant dans le temps (froid et humidité). Du coup j'hésite, car ça va pas servir avant un an ou deux (faut d'abord construire la maison), et un répéteur wifi près d'une fenêtre sera peut-être suffisant (actuellement ça sort très mal de la maison). Je dois tirer tout ça maintenant car l'accès au fourreau va devenir bcp plus compliqué ensuite… La fibre ne craint pas grand chose surtout si c'est dans un fourreau. Enfin cela craint les , mais a priori pas grand chose coté condition météo. Je reviens du massif central ou on déploie la fibre en aérien donc c'est pour te dire qu'avec le bon type de câble zéro problème. Et conseil fait le avant qu'il soit trop tard; tu vois moi quand j'ai acheté mon appart je n'ai pas câblé et maintenant je vais faire du bricolage pas très propre. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Revendeur cable RJ45 au métre
Merci à tous pour ces réponses. J'ai appris quelques trucs, notamment l'existence du CCA (je comprends pourquoi, le cuivre est cher, mais je ne savais pas qu'on en était arrivé là). Je vais donc partir sur du cat6 classique bien raide, mon ambition étant le 1G en passant par des gaines existantes. Je pourrais fibrer mais je n'ai pas le matériel, et pour le moment çà se terminerait avec des convertisseurs, donc on verra quand cela se présentera. Par ailleurs si par hasard quelqu'un sur la liste en RP possède du rab, je peux échanger contre divers matos en stock (cpe cisco divers, petit fw srx, mediaconv, sfp, xfp, etc..) en MP. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [BIZ] Revendeur cable RJ45 au métre
Bonne année 2021 amis des réseaux ! Bonne résolution de l'année (entre autre choses) je vais enfin me décider à câbler mon appartement. J'aurais donc besoin d'acheter du câble RJ45 CAT6 ou 7 au mètre (200m environ). Retiré du business réseau si vous avez des bons revendeurs à me conseiller je prends. Merci. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] lien de transit SFR
Bonjour, Latence, packet loss quelconque ? Quel type de lien de transit ? sur quel medium ? btw pourquoi prendre du transit chez SFR ? (seul transitaire disponible ?) Cdt, On 18/12/2020 11:52, Nicolas Parpandet wrote: Bonjour, Nous avons un nouveau lien de transit 1Gbits/s avec SFR, l'UDP monte bien à 850Mbits, mais une session tcp plafonne à 100Mbits/s comme si il y avait une QOS quelque part sur les sessions TCP, (le chiffre de 100Mbits/s revient tellement souvent dans nos tests, la probabilité que cela soit lié au hasard me semble faible...) De plus, avec une dizaine de sessions tcp en // , le débit global plafonne à 350Mbits... Cela fait plusieurs semaines que nous échangeons dans tous les sens avec l'opérateur (iperfs etc), c'est bien sur à nous de prouver le problème, et cela n'avance pas ! est-ce que quelqu'un sur la liste aurait déjà rencontré ce type de limite avec cet opérateur ?, nous avons fait énormément de contrôles de notre côté, il me semble que c'est bien en face le soucis ..., il peut toujours subsister un doute, mais si quelqu'un à une expérience sur le sujet ! Merci, A+ Nicolas --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Devis Diagnostic CRC Fibre
Bonjour, Tu peux déjà commencer par lire les niveaux optiques sur tes interfaces/sfp. Cela te donnera un début d'idée de si tu es complètement limite niveau budget optique ou pas. Sinon cela peut être aussi tes SFP; as tu testé de changer une paire ? Cdt, On 17/12/2020 11:49, Fabien wrote: Bonjour la liste, Je travaille dans l'équipe réseau d'une entreprise qui gère une infra cloud répartie sur 40 racks eux-mêmes répartis sur 3 datacenters en région parisienne (2 Equinix et 1 Interxion). Ces datacenters sont interconnectés par 3 fibres noires qui sont exploitées via des muxs passifs 40 canaux. Nous rencontrons depuis quelques mois de sérieux problèmes de CRC sur une quinzaine de chemins fibre qui transportent de l'IP ou du Fibre Channel. Au vu de la complexité de l'infra (passage sur plusieurs FON vis des muxs, en MMR, sur plusieurs datacenters) et des techniques à utiliser (réflectos, tests BERT, etc.) nous avons besoin d'assistance pour diagnostiquer la cause de ces CRC et de conseil pour la solution à appliquer. Si quelqu'un parmi vous (ou vos connaissances) peuvent répondre à notre demande n'hésitez pas à me contacter (jamrek[at]gmail.com) pour avoir plus détails. Cordialement, Fabien --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Qui a cassé Google ?
Yes au moins la console GCP, Gsuite, etc.. On 14/12/2020 13:03, Stephane Bortzmeyer wrote: YouTube qui affiche un joli message d'erreur et, apparemment, d'autres services Google en carafe. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Retour d'expériences AWS
On 23/11/2020 18:50, Wallace wrote: En dehors de ce problème légal, attention à l'utilisation des fonctionnalités avancées des clouds, il vaut mieux déployer ses propres instances avec les services que l'on veut et que l'on maîtrise plutôt que de s'enfermer dans une solution AAS et ne plus pouvoir bouger à moins de redévelopper les connecteurs API et souvent les applis. Avec une solution maitrisée en interne tu peux rapidement réinstaller dans un autre cloud avec une simple migration dns et des données. Quand tu utilises la base de donnée managé, le load balancer, le ... ben t'es bien coincé. Plutôt pour Frsag mais c'est intéressant. En effet c'est une des grosses questions qu'il faut se poser quand on va dans l'un des trois gros cloud publique. Quel degré d'adhérence tolérer pour mon déploiement ? D'un coté tu voudrais avoir le moins d'adhérence possible, donc en faisait du pur IaaS. D'un autre coté utiliser un cloud sans ses services managés c'est perdre une grande partie de son intérêt. Ce que je préconiserais c'est d'utiliser les services managés avec parcimonie, et de surtout regarder leur compatibilité. Par exemple : LB , pas de problème il s'agit de reverse proxy https classiques, RDS(aws) pour Mysql/Postgres, pas trop de problème puisque c'est standard et que tu peux re-migrer tes datas sur du Mysql/Maria à toi. Pareil avec ElastiCache qui est compatible Redis. S3 est un as plus intéressant, car utiliser un cloud publique sans utiliser son object storage c'est se passer d'une ressource plus qu'avantageuse. L'ennui c'est que S3 est devenu un standard de facto (voir Minio par exemple) mais pas disponible partout (notamment sur Azure). Résultat ma recommandation la dessus serait de l'utiliser mais avec une petite couche d'abstraction. Pour le reste des autres services types DynamoDB (pourtant bien pratiques) ou SNS/SQS j'essayerais de m'en passer, car c'est en effet trop se locker. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Retour d'expériences AWS
Hello réponse inline de ce que j'en connais. On 23/11/2020 15:38, Mickael Hubert wrote: Interco L2 avec des clients c'est possible ? Si on a du L2 remontant de TH2 par exemple, il y a moyen de remonter ce L2 en cross-co chez AWS ou un partenaire à eux (j'ai peur de votre réponse ...) ? Nope. No way. Déjà chez en interne chez AWS il n'y a pas de L2 étendu entre AZ et encore moins entre région, alors avec l'extérieur. Peut-on gérer ses accès VPN, ses plages d'IP (Ex: ne gérant pas l'overlap IP, on a fait le choix de bosser avec la RFC 6598 pour éviter les conflits avec les subnets de nos clients) peut-on attribuer n'importe quel subnet à nos VM ? Coté réseau et vpn oui tu peux/doit créer ton propre plan d'adressage avec toutes les IPs rfc1918 à disposition. Coté VPN tu peux même faire un peu de BGP pour échanger tes routes. A-t-on le choix de son routeur (on bosse pas mal avec FRR), encore faut-il pouvoir router soi-même ... ? Auparavant ce n'était pas possible du tout, tu étais obligé d'utiliser les boites noires AWS, aws-gateway ou aws-nat-gateway. Depuis la situation a évolué pour permettre d'utiliser tes propres gateway sur une instance ec2 (principalement pour autoriser la vente d'appliance sur la market place je dirais). Une nouvelle feature vient même de sortir permettant de redonder/load balancé ces gw : https://aws.amazon.com/fr/elasticloadbalancing/gateway-load-balancer/ En revanche pose toi bien la question de pourquoi tu voudrais faire ça. Généralement la seule bonne raison valable serait de faire de l'inspection de trafic centrale ou de mettre un firewall centralisé (ce qui est à l'opposé du modèle de sécurité AWS) Côté VoIP, j'imagine que ça "marche", car de mémoire twilio sont full AWS. Mais côté NAT etc... ça marche comment ? Je crois savoir qu'on a jamais d'IP publique au cul de sa VM, mais que c'est du NAT 1/1. Ça se passe bien ? Tu peux tout à fait associer une IP publique à une instance. Deux mode soit tu laisses AWS choisir, le mode par défaut, mais dans ce cas il s'agit d'une IP aléatoire à chaque ré-initialisation de l'instance, soit tu attaches une Elastic IP à une instance qui ne changera jamais. Pas besoin de NAT in sur AWS généralement. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [ALERT] FREE et/ou Internet saturé
Bien qu’intéressant je pense que la discussion aura plus de sens sur le forum de lafibre.info. -- Raphael Mazelier On 17/11/2020 11:13, Daniel via frnog wrote: Exactement. En tous cas je confirme le problème, je n'arrive pas plus à joindre la ligne FREE Rosace à partir d'une fibre FREE à Strasbourg. À partir de chez Hetzner la dernière station vue par mtr est decix.proxad.net --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Baie
On 24/09/2020 08:25, David Ponzone wrote: Plutôt à Tokyo ou LA ? J'ai un peu de place dans la baie dans mon garage :p --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] UDP - DDOS : Solution globale possible ?
On 03/09/2020 16:54, Olivier Cochard-Labbé wrote: En plus d'avoir une équipe dédiée à l'optimisation des codecs audio/vidéo, tu en as une dédiée a améliorer les différents protocoles de congestion TCP (BBR, RACK). Il va être simple de faire évoluer la pile TCP de tes propres serveurs, mais tu vas très vite être bloqué par le côté client: Il faut déjà une certaine taille avant de pouvoir avoir ce genre d'équipe. Youtube, Netflix et peut être quelques autre ont la taille suffisante et un intérêt à le faire. Après de ma connaissance sur le pseudo streaming l'effort se porte plutôt sur les codecs que sur le transport, ou du moins je ne pas le sentiment qu'on aille au delà d'optimiser tes serveurs CDNs (couverture et coût). Dans le cas de la svod on travaille sur des chunks plutôt très gros, et ou la latence n'est pas un gros soucis. Donc l'overhead de TCP me semble plutôt marginal. Cela pourrait être différent sur des use case de low-latency. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] split BX vers LX/LH
Si on reste dans cette logique (qui me parait bonne), une optique colorée ne l'est que du coté transmission, le coté réception ne change pas car c'est le demux qui se charge d'isoler le bon lambda. Le coté réception d'une optique colorée serait-il donc le même que celui d'une optique grise ? De ma compréhension absolument. Cdt, -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] split BX vers LX/LH
De souvenir les optiques sont très très permise en réception. Donc tu peux beaucoup bricoler et monter des liaisons avec des optiques différentes de chaque coté. Puissance ou longueur d'onde n'ont pas forcément besoin d’être aligné et cela peut dépanner quand tu n'as pas la bonne optique en stock. -- Raphael Mazelier On 05/08/2020 09:25, Duchet Rémy wrote: J'avoue que le coup des optiques LX qui lisent le 1490 en provenance d'une BX alors qu'elles attendent du 1310, j'ai pas encore fait. Je me demande toujours si t'es pas en train de pratiquer la pêche au troll, d'ailleurs. Moi Saint-Thomas :P Testé recement, (par erreur) 1535 (DWDM) => 1310 . Le lien monte sans soucis. Après, j'ai pas fait de test de perf.. Rémy --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Choix de routeur en 2020
Question bête sur Nokia : au pif aiguisé, je ne demande pas de la science. Considérant que je ne connais rien à Juniper (ce n'est pas vrai, mais pas grand chose); à part Cisco, si je devais apprendre un nouveau routeur de coeur, en 2020, qu'est ce que tu ferais à ma place ? apprendre Juniper, ou apprendre Nokia ? Franchement si tu as les bases du réseaux, une syntaxe est une syntaxe. C'est un peu comme apprendre un nouveau langage de programmation en plus simple. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Perte chez Orange / OTI
On 22/06/2020 12:24, Johann wrote: Hello, On a effectivement une grosse saturation entre Zayo et Orange, cela semble être dû à un port down + l'arrêt des annonces de Orange sur HOPUS. Ouch. Ça doit faire un poil trop de report de trafic :/ -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] NAT, Free et ports bas
Bonjour, A partir de quand tu considères qu'un port est bas ? 1024 ? Cdt, On 09/06/2020 09:06, fabrice prigent wrote: Bonjour à tous, Première question de ma part. Je suis responsable sys et réseau dans une université avec 2 étudiants. La période actuelle nous permet de découvrir des problèmes "plutôt rares", mais gênants, le dernier en date étant la transformation NAT A+P de Free (les exemples qui nous sont remontés sont systématiquement liés à Free pour l'instant). Notre Firewall est conçu pour bloquer toutes les communications "non standard", telles que des ports bas vers d'autres ports pas. Mais le NAT A+P de Free ne semble pas du tout prendre en compte ce principe, ce qui fait que nous bloquons un nombre "important" de requêtes légitimes. A la dernière analyse, ce comportement (connexion d'un port bas vers le port 80 par exemple) était à 96% du à des scanners de vulnérabilités (on ne va pas dire pirates.), mais les 4% restants sont des étudiants et personnels chez Free. (Je résume). Docteur(s), suis-je psycho-rigide ? Sommes-nous le seul cas ? Dois-je : - prier le dieu Free afin que dans sa clémence il corrige ce comportement - me dire "ranapéter, je continue de bloquer" - me dire "Ils sont trop grands, je suis trop petit, j'accepte" - multiplier par 4 la taille de mes règles iptables afin de désactiver les ports bas quand il s'agit de free et ainsi rendre honneur au plat préféré de mes femmes : les spaghettis - faire honneur à mon pays du rugby, avec un magnifique bottage en touche en disant aux utilisateurs "takademanderuneipfisc" - "42" Merci d'avance de vos réponses. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Patchbox a encore frappé.....
Pour tous ceux qui ont besoin de racker seul du matos assez lourd, On m’a envoyé ça, Patchbox a encore frappé! https://patchbox.com/setup-exe <https://patchbox.com/setup-exe> Ca mérite un award du génie! Franchement c'est top. Tout ceux qui ont déjà bricolé en DC peuvent témoigner qu'on a tous fait des bricolages plus ou moins exotiques pour racker des éléments lourds ou pour avoir une tablette pour laptop. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] system de ticket pour support
Je ne sais pas. A titre personnel j'ai plutôt un souvenir positif de RT. En revanche j'ai fait des cauchemar avec OTRS. On 04/06/2020 18:08, David Ponzone wrote: Mais qu’a donc la Terre entière contre Request-Tracker…. Le 4 juin 2020 à 17:59, Jean-Yves LENHOF a écrit : Quelques outils OpenSource : OTRS Itop GLPI Après plus orienté Dev Web : Mantis Redmine Bugzilla --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Coupures câbles dans le sud de Paris
On 05/05/2020 16:09, François Lacombe wrote: Hypothèse très partiellement fondée : l'utilisateur habituel de la gaine verte a aussi été impacté https://www.zdnet.fr/actualites/une-coupure-de-reseau-orange-detectee-dans-le-sud-est-de-paris-39903247.htm Beaucoup d’opérateurs ont pris la foudre ce matin... Je n'ai pas dit qu'il s'agissait d'un acte ciblé contre un opérateur. J'espère réellement que la justice fera son œuvre et tirera cette sombre histoire au clair. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Coupures câbles dans le sud de Paris
On 05/05/2020 15:47, Raphaël Jacquot wrote: bizarre, tous ces cables gainés de vert qui s'en tirent "miraculeusement"... #JDCJDR Effectivement il s'agit très clairement d'un acte de malveillance ciblé. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Stack de logs / netflow
On 28/04/2020 13:21, Remi Desgrange wrote: Il est vrais que les outils de la stack ELK bouffe beaucoup (trop) de ressources. Mais quand tu a beaucoup de données, La JVM tu t'y retrouve. C'est pas pour rien que les stacks big data tourne sur la JVM (le log de 700 équipements c'est pas du big data, on est d'accord). Étant dans le milieu de la bigdata depuis peu, je ne suis pas sur que la raison profonde du choix de la JVM soit la performance. Je crois que c'est plutôt affaire écosystème (la plupart des frameworks sont ecris en Java/Scala), et que c'est avant tout car ces langages ont une certaine expressivité qui manquent à des langages plus bas niveau, et donc qu'il serait extrêmement pénible de manipuler des structures de données complexes dans des lesdits langages. (Il y aussi énormément de python mais la on ne parle même plus de performances.) -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Stack de logs / netflow
On 28/04/2020 12:47, Xavier Beaudouin wrote: Okay rrdtool ne permet pas d'avoir des stats journalières précises a plus d'un mois mais donnent largement ce qu'il faut pour avoir des métriques d'utilisation d'une plateforme. Il y a un truc qui est vrai dans ce que tu dis c'est que toutes les solutions actuelles à base d'elastisearch, ou tsdb c'est la difficulté à gérer de l'historique long et le downsampling. (parfois il m'arrive de regretter rrd pour ce point précis pas pour le reste). Alors pourquoi utiliser un machin en java qui est un OS sur un autre OS alors qu'on pourrais utiliser des API normales d'un OS (oui la libc... / libthread). Pour faire un parallèle : nginx vs apache voila ce que j'en pense (hormis les problèmes de licences et de FUD liées au modele de dev). Pour le coup je ne comprends pas trop l'analogie. Nginx est plus simple et plus performant qu'Apache. Je vois Nginx comme un gros framework orienté web et perf (mais c'est peut être parce que j'ai codé des modules nginx). -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Stack de logs / netflow
Bonsoir, Tu parles de deux choses complètement différentes : la centralisation de logs d'équipements et la collection de flow réseaux. Pour les logs la plupart des équipements ne savent encore que parler syslog, mais ce n'est pas le problème. Ensuite tu dois choisir une solution pour ingérer, découper, classer, stocker et exploiter ces logs. Coté stockage en open source Elasticsearch est omniprésent pour le stockage des logs (ce qui peut faire sens, vu qu'il s'agit souvent de stocker des documents textes indexés et de faire des recherches). Ce n'est clairement pas le plus performant mais c'est un standard connu. Ensuite vient le choix de l'ingestion et de l'interface de visualisation. La stack E(L|F)K est la plus présente, mais à titre personnel ce n'est pas ma préféré (n'étant pas un grand fan de Kibana, ni de logstash, ni de Fluent). Pour un usage modéré j'ai plutôt de bon souvenir de graylog. A noter qu'il existe des alternatives plus jeune mais prometteuses (voir Loki de la cncf). Ensuite Splunk très bien, mais cher. Pour les flows je dirais que c'est encore plus ouvert. J'ai personnellement mis en place beaucoup de solutions autour de pmacct > message broker > agrégateur > tsdb (ou base rapide) homemade. C'est un peu de travail à mettre en place néanmoins. Il existe beaucoup de solutions commerciales peu chère qui font le boulot. -- Raphael Mazelier On 28/04/2020 11:38, Christian d'Autume wrote: Bonjour la liste, On lance des réflexions chez nous pour refondre notre stack de centralisation de logs (type syslog, voir netflow); et regardons un peu ce qui se fait principalement en opensource. Vous auriez des retours d'expériences sur des appliances types elk / splunk, pour un parc hétérogène (~700 équipements: nxos, ftd, ios, asa, juniper ...) ? En vous remerciant d'avance pour vos retours. Christian --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Devis Observium
On 08/04/2020 09:25, David Ramahefason wrote: Euh je pense que Cécile connaît ce genre de structure et sait comment ça marche ... Bizarre de penser autrement... Dans un ex travail dans une grosse structure nous avions l'habitude pour ce genre de demande de passer par une société écran. Cette société nous fournissait un devis acceptable par nos différents strates de contrôle, et effectuait l'achat pour nous. Évidement cette société prenait une petite marge mais bon quel confort. On pu faire passer des choses impossible de ce style (petite licence, matos en vrac, même achat au grey market) -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] accès à https://myaccount.google.com
Non mais je sais :^p mais des filtres en 172/8 j'en ai vu un paquet dans ma carrière. Cdt, On 06/04/2020 17:29, Yoann Moulin wrote: Le 06/04/2020 à 17:27, Raphael Mazelier a écrit : 172. Il n'y a que moi que cela fait tilter ? :) NetRange: 172.217.0.0 - 172.217.255.255 CIDR: 172.217.0.0/16 NetName:GOOGLE NetHandle: NET-172-217-0-0-1 Parent: NET172 (NET-172-0-0-0-0) NetType:Direct Allocation OriginAS: AS15169 Organization: Google LLC (GOGL) RegDate:2012-04-16 Updated:2012-04-16 Ref:https://rdap.arin.net/registry/ip/172.217.0.0 NetRange: 172.16.0.0 - 172.31.255.255 CIDR: 172.16.0.0/12 NetName:PRIVATE-ADDRESS-BBLK-RFC1918-IANA-RESERVED NetHandle: NET-172-16-0-0-1 Parent: NET172 (NET-172-0-0-0-0) NetType:IANA Special Use ;) On 06/04/2020 17:20, Clément Guivy wrote: bonjour, Des users nous remontent des problèmes pour accéder à https://myaccount.google.com/ (l'authentification de google pour ses différents services) depuis un site en particulier (qui a son propre accès internet). Concrètement dans ce cas c'est un timeout, on ne reçoit aucun paquet en réponse de la part de google. Mes constatations : Depuis le site pour lequel cela ne fonctionne pas, myaccount.google.com résoud sur 172.217.19.238 Depuis le site pour lequel cela fonctionne, myaccount.google.com résoud sur 216.58.206.238 Depuis le site qui ne fonctionne pas, le ping vers 172.217.19.238 ne répond pas, le ping vers 216.58.206.238 répond Depuis le site qui fonctionne, le ping vers les deux IP répond Depuis le site qui ne fonctionne pas, le traceroute vers 172.217.19.238 arrive jusque chez google, dernier saut 216.239.59.209 (IP google), puis pas de réponse au delà Depuis le site qui fonctionne, le traceroute vers 172.217.19.238 arrive à destination Si je modifie les résolveurs des PC du site qui ne fonctionne pas pour utiliser les mêmes que ceux du site qui fonctionne, tout fonctionne bien. Donc en conclusion, depuis le site qui ne fonctionne pas, la résolution DNS de myaccount.google.com nous répond une IP qui n'est pas joignable depuis ce site. Un traceroute vers cette IP montre que 1) elle est joignable depuis d'autres endroits, donc elle n'est pas entièrement HS, et 2) quand on tente de la joindre on arrive jusque chez google, donc on ne peut pas incriminer notre FAI sur cette base. Des idées ? Autre curiosité pas forcément liée au problème, je remarque qu'on reçoit de nos transitaires des annonces en provenance de l'AS google plus spécifiques que ce que google annonce sur France IX. Exemple Google annonce 216.58.192.0/19 via France IX, mais par transitaire on reçoit 216.58.196.0/23, 216.58.198.0/24, 216.58.199.0/24 etc. Ca vous semble normal ? --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] accès à https://myaccount.google.com
172. Il n'y a que moi que cela fait tilter ? :) On 06/04/2020 17:20, Clément Guivy wrote: bonjour, Des users nous remontent des problèmes pour accéder à https://myaccount.google.com/ (l'authentification de google pour ses différents services) depuis un site en particulier (qui a son propre accès internet). Concrètement dans ce cas c'est un timeout, on ne reçoit aucun paquet en réponse de la part de google. Mes constatations : Depuis le site pour lequel cela ne fonctionne pas, myaccount.google.com résoud sur 172.217.19.238 Depuis le site pour lequel cela fonctionne, myaccount.google.com résoud sur 216.58.206.238 Depuis le site qui ne fonctionne pas, le ping vers 172.217.19.238 ne répond pas, le ping vers 216.58.206.238 répond Depuis le site qui fonctionne, le ping vers les deux IP répond Depuis le site qui ne fonctionne pas, le traceroute vers 172.217.19.238 arrive jusque chez google, dernier saut 216.239.59.209 (IP google), puis pas de réponse au delà Depuis le site qui fonctionne, le traceroute vers 172.217.19.238 arrive à destination Si je modifie les résolveurs des PC du site qui ne fonctionne pas pour utiliser les mêmes que ceux du site qui fonctionne, tout fonctionne bien. Donc en conclusion, depuis le site qui ne fonctionne pas, la résolution DNS de myaccount.google.com nous répond une IP qui n'est pas joignable depuis ce site. Un traceroute vers cette IP montre que 1) elle est joignable depuis d'autres endroits, donc elle n'est pas entièrement HS, et 2) quand on tente de la joindre on arrive jusque chez google, donc on ne peut pas incriminer notre FAI sur cette base. Des idées ? Autre curiosité pas forcément liée au problème, je remarque qu'on reçoit de nos transitaires des annonces en provenance de l'AS google plus spécifiques que ce que google annonce sur France IX. Exemple Google annonce 216.58.192.0/19 via France IX, mais par transitaire on reçoit 216.58.196.0/23, 216.58.198.0/24, 216.58.199.0/24 etc. Ca vous semble normal ? --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Filtrage DNS chez SFR
On 20/03/2020 20:53, Baptiste Chappe wrote: Bonsoir, J'ai eu la même ce jour avec un client sur une Freebox. Je monte le VPN avec un split. Seul le trafic vers le range precis passe dans le tunnel. Impossible de ping la ressource en DNS. Je change le DNS par Google et paf ca marche. Je suis un dingue en publiant dans le DNS des clients une IP privée ? J'ai rarement la chance d'avoir un DNS en local sur les sites (TPME 5 à 30 personnes). Ex : imprimante.toto.com = 192.168.1.2 Merci Messieurs merci de ne pas tous mélanger. Les résolveurs de Free sont connus pour filtrer les rfc1918. Les résolveurs de SFR/ex-NC semblent ok (et effectivement ne répondent que depuis le réseau SFR/ex-NC). A priori mais c'est à confirmer cela n'impacte qu'un certain type de box SFR (l'ingénierie SFR est sur le coup, merci à eux). PS : non ce n'est pas complètement fou comme pratique mais tu t'exposes à ce genre de problèmes. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Filtrage DNS chez SFR
On 20/03/2020 19:43, Alarig Le Lay wrote: dig -t A roucool.int.no.swordarmor.fr @89.2.0.1 Non cela semble venir de la box. On debug en off et on vous donnera les conclusions quand on aura trouvé. Cdt, -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Réduction du bitrate de Netflix
On 20/03/2020 17:59, Ducassou Laurent wrote: Le vrai problème de fond de cette "non information" est que Netflix prends cher comme youtube à une époque... La seule différence c'est qu'ils ne peuvent pas se planquer derrière le "petit bout de doigt" du "c'est gratuit donc râlez pas trop !" car ils n'ont pas fait des tuyau assez gros avec les principaux FAI des principaux pays... (car oui, les serveurs de cache qui sont là pour absorber chez les FAI, là ils sont out game car vu que les gens ont "que ça a faire" ils vont au très fond du catalogue que personne regarde d'habitude !) Le hit ratio a du baisser sur les OCAs (je n'ai pas les stats mais ça semble logique). Ceci dit je pense que le facteur limitant se situe vraiment coté FAIs sur le backbone interne. Donc finalement ce n'est pas une si mauvaise décision, après les ISP auraient été forcés de prendre ce genre de mesure eux même mais c'était techniquement plus délicat. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Filtrage DNS chez SFR
On 20/03/2020 12:44, Paul Rolland (ポール・ロラン) wrote: d'une manière ou d'une autre les requêtes DNS (ALG dns ?). Questions cons : - est-ce que 192.168.0.x correspond au "lan local" de ta box ? - si oui, est-ce que tu as le meme comportement avec des adresses RFC1918 qui ne font pas partie de l'adressage de ce LAN local ? Non tu as le même comportement avec 10/8, 172/12 et 192.168/16. Testé et désapprouvé. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Filtrage DNS chez SFR
Bonjour David, enchanté. Je serais ravi d'échanger avec vous pour déboguer ce sujet. Les dns reçu en dhcp sont 89.2.0.1 et 89.2.0.2. Je ne sais pas si le filtrage se situe au niveau de ces serveurs. J'en doute même cf l'exemple : Derrière box SFR : dig rfc1918.futomaki.net +short > timeout dig @9.9.9.9 rfc1918.futomaki.net +short> timeout Depuis ailleurs (disons une vm dans le cloud) : dig @9.9.9.9 rfc1918.futomaki.net +short > 192.168.0.43 Donc my guess c'est que la box intercepte d'une manière ou d'une autre les requêtes DNS (ALG dns ?). Cdt, -- Raphael Mazelier On 20/03/2020 11:01, GAVARRET, David wrote: Bonjour Raphael, pourriez-vous préciser les IP des resolvers SFR en question ? Je suis directement en charge de ces plateformes, et je peux vous assurer qu'on ne fait aucune bidouille dans le filtrage des réponses en dehors de nos obligations règlementaires. D'autre part, il n'y a aucun filtrage de trafic à destination de resolveurs tiers. Je vois mal comment nous pourrions en interdire l'usage ne serait-ce qu'à nos clients B2B/Transit IP. A disposition pour investiguer sur ce sujet. Cordialement, -- David Gavarret --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] Filtrage DNS chez SFR
Hello, c'est vendredi alors je me permets. Depuis cette semaine nous sommes tous en wfh et nous avons noté un comportement assez laid de la part de SFR. Comme beaucoup nous avons des zones dns publiques qui pointent sur des enregistrements rfc1918. Les résolveurs SFR filtrent ces réponses, soit. En revanche ce qui est inédit c'est que lorsqu'on set le resolveur de cloudflare, ou google, voir faire un dig @1.1.1.1 iprfc1918.pipo.net, cela timeout. C'est donc filtré à un endroit et ça c'est très laid, car cela veut sans doute dire qu'avec SFR on ne peut pas simplement changer de serveur dns, ou du moins être sur que c'est le serveur pointé qui te réponds. Ceci dit un dig @9.9.9.9 isitblocked.org renvoie bien un nxdomain, donc cela ne semble filtrait que les rfc1918. Qu'est ce que cela vous inspire ? C'est vendredi matin j'ai peut être raté quelque chose. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)
Si tu savais… :D Je bloque sur un point sur l'idée de relais RTP : que se passe-t-il quand le RTP learning foire ? Fin des appels ? Parce que là, je viens de tester entre du Linphone winwin et Linux. Ça ne fonctionnait pas avant (donc le VPN OpenVPN apporte quelque chose) et, surtout, je constate que le RTP learning n'arrive pas au stade « Complete » et que les softphones échangent en P2P. Que va-t-il se passer pour eux si je force un relais RTP ? Moi je comprends qu'ils ne pourront plus se téléphoner… Pas cool. Le rtp learning c'est une invention d'asterisk j'imagine qui doit être une fonctionnalité qui essaie de découvrir la topologie réseau et donc setter les adresses ip dans le rtp. C'est aussi pour cela que je n'aime pas trop asterisk, ca fait beaucoup de magie et a la fin on ne comprends pas vraiment ce que l'on fait. Une bonne manière de bien comprendre c'est de démarrer avec un opensips/kamailio et du rtpproxy/mediaproxy. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)
On 18/03/2020 14:34, David Ponzone wrote: Je connais pas ton archi, mais si derrière t’as une Patton/Audiocodes/Bero qui peut joindre les endpoint, alors oui, tu peux faire du direct. Sinon tu es obligé d’utiliser l’* comme B2BUA/SBC. Oui mais la encore c'est casse gueule. Ce n'est pas pour rien qu'on a inventé les rtp-proxy. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)
On 18/03/2020 13:47, Guillaume LUCAS wrote: Côté Asterisk, donc. J'suis pas encore chaud pour qu'Asterisk soit relais RTP de tout le monde… D'un autre côté… avec le RTP autolearn, il l'est implicitement depuis longtemps, si je comprends bien ? Pourquoi ? sans transcoding c'est juste la copie de paquet, ça coûte que dalle en cpu. Pareil en réseau. Et ça va résoudre 90% de tes problèmes. Mon conseil tu fais tout passer par ton asterisk SIG+RTP, et tu trouve la conf qui va bien pour laisser les ports RTP ouverts. (parce que sinon effectivement tu vas tomber dans les problèmes de comm semi blanche à 30s, enfin le temps du timeout d'un port nat udp sur le fw local). Sinon si tu peux centraliser la conf de tes linphones ca serait aussi pour toi le meilleur, avec pareil l'option qui va bien. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)
Cela me ramène quelque année en arrière. Et cela me rappelle aussi pourquoi on posait des box chez les clients. (coucou les ex-B3G, Ipnotic, Paritel) Faire de la Voip si tu ne maîtrise pas le lan client c'est possible mais source d'emmerdements infinis. Comme déjà mentionné il faut absolument que ton RTP soit in path de ton asterisk (rtp proxy , whatever). Au final je me demande si tu ne t’embête pas plus avec un vpn que sans. (alors surtout un ASA qui si tu n'y prend pas garde va joyeusement faire n'importe quoi avec tes paquets SIP, a se demander d'ailleurs pourquoi on a crée des ALGs SIP pour qu'au final la 1ere chose à faire c'est de les désactiver). En public ICE/STUN/TURN peuvent définitivement aider. Après si pour X raison tu es obligé d'utiliser un VPN, bin bon courage. Wireshark va être ton ami proche des prochains jours. Good luck. -- Raphael Mazelier On 17/03/2020 18:43, Guillaume LUCAS wrote: - Mail original - De: "frnog" Réussis tu à pinguer l'IP en 192.168.x.y à partir du PABX ? Non. Et surtout, je ne veux pas ping les réseaux domestiques de mes usagers. Ce n'est pas mon rôle d'utiliser notre VPN pour accéder à leur réseau local. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] HAProxy multi DC
Tout dépend du point de vu :) A une époque pas si lointaine quand le devops n'existait que dans nos cauchemars (pardon rêves ;)) les plus fous, c'est l'infrastructure seule qui portait cette responsabilité. Ce paradigme a quelque peu évolué depuis et on retrouve cette notion des deux côtés de la barrière. D'ailleurs c'est aussi l'intérêt de cette approche dev/ops car au final si on veut quelque chose d'efficient il vaut mieux se coordonner ;) Perso je doute que tout se passe d'un côté ou de l'autre. Tu as raisons il n'y a pas de coté. On devrait être tous est focus sur ce qui importe aka délivrer un service à un client. Au début tout était plus simple car maîtrisable par les même personnes. Je ne sais pas quand exactement on a commencé à trop spécialiser les informaticiens et à ne plus se parler. Il y a effectivement une période ou on pouvait entendre régulièrement : la redondance ce n'est pas mon soucis en tant que développeur, l'infra doit me fournir un runtime résilient, pareil pour le réseau. De manière ironique le cloud a participé à cette rectification, avec les fameux application "cloud ready", et/ou remettre au centre le fait que l'infra n'est pas infaillible et que le meilleur endroit pour savoir ce qu'il se passe c'est encore dans l'application. Le mouvement "devops" est finalement une normalisation de ce qui aurait du toujours être. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] HAProxy multi DC
On 05/03/2020 21:54, Philippe Bourcier wrote: Ca n'aurait pratiquement aucun intérêt... puisque c'est déjà ce que ferait un OS/browser. Je ferais plutôt : 1. le client JS fait sa requête DoH 2. il voit N CNAMEs : srv[1,2,3...].frnog.org 3. il lance 2 threads de connexion (get d'une page de status) vers 2 des N serveurs 4. il choisit celui qui répond "tout va bien" (ce qui permet de désactiver un node (ie: lors d'une mise en prod)) et qui a la meilleure latence... Le tout est contenu avec un timeout de 150ms... si aucun des 2 n'est OK, on passe au(x) node(s) suivant(s)... 5. il lance la/les requêtes API vers cet élu... si failure, re-bascule sur un des autres (avec un sleep++ plus on retry, passé les N serveurs du pool)... Oui c'est ce que je pensais. 3. _caches DNS_ : on en revient au cas DNS classique et au problème du TTL mini effectif de 20 minutes. En DoH on a le contrôle sur le serveur qu'on interroge et on peut remonter directement à l'origine (SOA) et court-circuiter les caches (ce qui revient à ignorer le TTL) On ignore pas le TTL on aura le vrai TTL. On pallie des comportements de certains ISP peu scrupuleux. Btw DoH sera bientôt utilisé par défaut dans pas mal de browser ce qui nous facilitera la tache. Je pense même que les gros vont finir pas imposer des serveurs DoH par défaut overridant ceux du système. 4. _latence DNS_ : à benchmarker (DoH en JS à l'origine vs. DNS classique via des resolvers qui cachent) Oui c'est un des gros points à vérifier. La latence initiale risque de ne pas être fameuse. A voir si c'est acceptable. Pour une grosse SPA je pense que ça passe. Faudrait clairement faire un PoC... I'm in. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] HAProxy multi DC
Yes le fameux compute@edge. Très pratique mais pas très donné pour le
moment.
--
Raphael Mazelier
On 05/03/2020 12:43, Théophile Helleboid wrote:
Avec les "Workers" qu'on peut exécuter directement chez le CDN, on
peut faire un mix.
Par exemple :
- Un worker qui vérifie chaque upstream…
- et qui génère un fichier de configuration avec au moins un upstream
qui fonctionne : { api_host: "https://api1.example.com; }.
L'application Javascript télécharge ce fichier de configuration et
utilise ce hostname pour toutes les requêtes d'API
- ou juste une page minimale qui permet de charger le javascript
depuis le bon upstream :
Ça permet de mettre un peu de logique dans le "worker" (optimisation
géographique, vérifications précises de l'état de l'upstream), sans
tomber dans l’extrême et l'utilisation d'IP.
On Thu, Mar 5, 2020 at 2:01 PM Raphael Mazelier wrote:
Je crois que l'on a mélangé un peu plusieurs discussions mais au final
on en revient toujours au même débat : ou placer la redondance ? coté
infra ou coté applicatif ?
La redondance infrastructure est d'une certaine manière plus facile à
réaliser mais moins efficace ou plus dure à mettre au point.
La redondance coté client est sans doute très intéressante si l'on
accepte de passer du temps coté client. C'est vrai pour qu'une page web,
on peut sans doute trouver des solutions intéressantes avec les
possibilités de bricoler en js actuelle.
Une squelette statique délivré via un CDN (avec un peu de cache), du js
qui fait des checks sur les différents serveurs de ressources,
construction de la page après. Ça doit se faire.
Même pas besoin de DoH en fait. D'ailleurs DoH coté client js, why not,
mais après il faudrait pouvoir faire comprendre au browser qu'il doit
utiliser ce qui vient d’être résolu pour le reste, ce qui est peut être
possible mais je ne sais pas comment faire.
Ca serait intéressant de faire un POC la dessus.
--
Raphael Mazelier
On 05/03/2020 00:50, Jonathan Leroy - Inikup via frnog wrote:
Le mer. 4 mars 2020 à 23:04, Philippe Bourcier a écrit :
Utiliser des cookies, en 2020 ? ... :)
Web Storage, JWT, sessionless... ?
Web Storage n'est pas fait pour stocker des infos de session
(n'importe quel script tiers sur la page peut accéder à son contenu).
JWT est une horreur à éviter à tout prix
(https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid).
Dans les faits le sessionless quasiment impossible pour une app web
sans utiliser JWT.
Donc oui, les cookies sont nécessaires en 2020. :)
Pour répondre à la question initiale :
- Vraie solution propre : si tu as besoin d'un failover sur un DC
secondaire, c'est que ton business est critique et que toute coupure
te coûte une somme non négligeable. Donc il te faut demander un /24
(ainsi qu'un /48, car nous sommes en 2020) à un LIR et l'annoncer en
BGP. Ton hébergeur n'est pas capable de faire ça ? Qu'il change de
métier (ou à défaut, tu peux changer d'hébergeur).
- Solution pas trop sale alternative : Cloudflare propose un LB dans
le cloud qui fait ça très bien et pour pas cher. Ça check les serveurs
de ton pool toutes les 15 seconds et il y a même une API.
---
Liste de diffusion du FRnOG
http://www.frnog.org/
---
Liste de diffusion du FRnOG
http://www.frnog.org/
Re: [FRnOG] [TECH] HAProxy multi DC
Je crois que l'on a mélangé un peu plusieurs discussions mais au final on en revient toujours au même débat : ou placer la redondance ? coté infra ou coté applicatif ? La redondance infrastructure est d'une certaine manière plus facile à réaliser mais moins efficace ou plus dure à mettre au point. La redondance coté client est sans doute très intéressante si l'on accepte de passer du temps coté client. C'est vrai pour qu'une page web, on peut sans doute trouver des solutions intéressantes avec les possibilités de bricoler en js actuelle. Une squelette statique délivré via un CDN (avec un peu de cache), du js qui fait des checks sur les différents serveurs de ressources, construction de la page après. Ça doit se faire. Même pas besoin de DoH en fait. D'ailleurs DoH coté client js, why not, mais après il faudrait pouvoir faire comprendre au browser qu'il doit utiliser ce qui vient d’être résolu pour le reste, ce qui est peut être possible mais je ne sais pas comment faire. Ca serait intéressant de faire un POC la dessus. -- Raphael Mazelier On 05/03/2020 00:50, Jonathan Leroy - Inikup via frnog wrote: Le mer. 4 mars 2020 à 23:04, Philippe Bourcier a écrit : Utiliser des cookies, en 2020 ? ... :) Web Storage, JWT, sessionless... ? Web Storage n'est pas fait pour stocker des infos de session (n'importe quel script tiers sur la page peut accéder à son contenu). JWT est une horreur à éviter à tout prix (https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid). Dans les faits le sessionless quasiment impossible pour une app web sans utiliser JWT. Donc oui, les cookies sont nécessaires en 2020. :) Pour répondre à la question initiale : - Vraie solution propre : si tu as besoin d'un failover sur un DC secondaire, c'est que ton business est critique et que toute coupure te coûte une somme non négligeable. Donc il te faut demander un /24 (ainsi qu'un /48, car nous sommes en 2020) à un LIR et l'annoncer en BGP. Ton hébergeur n'est pas capable de faire ça ? Qu'il change de métier (ou à défaut, tu peux changer d'hébergeur). - Solution pas trop sale alternative : Cloudflare propose un LB dans le cloud qui fait ça très bien et pour pas cher. Ça check les serveurs de ton pool toutes les 15 seconds et il y a même une API. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] HAProxy multi DC
Oui si on accepte d'utiliser un service tiers, un dns global type route53 est simple (peu cher) et efficace pour ce genre de redondance. On 05/03/2020 10:41, Thomas Quinot wrote: * Renaud RAKOTOMALALA, 2020-03-03 : - t'appuyer sur un service tier pour le DNS qui en conscience adaptera la réponse sur le ou les IP publiques de tes HAProxy Ça peut être une solution assez simple à mettre en œuvre avec AWS Route53, qui permet d'associer les RR retournés à des "health checks" (et/ou à d'autres critères tels que des estimations de latence, si on veut favoriser un serveur "proche", au-delà du simple partage de charge). Thomas. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] HAProxy multi DC
Résultat gslb avec gdnsd me semble une bonne solution. Les ttls court c'est moche mais tout le monde le fait alors bon. -- Raphael Mazelier On 03/03/2020 13:15, Mickael Hubert wrote: Un grand merci à tous pour vos retours ! BGP pas possible coté hébergeur, ses IP arrivent de façon indépendantes sur ses 2 DC, pas possible d'annoncer le subnet du DC A sur le DC B en cas de perte du DC A. J'ai bien un L2 entre les 2 DC, mais il ne me servirait que pour le côté privé. Et d'ailleurs ça casserait mon design L3 (car j'ai remonté un L3 au dessus du L2 fourni par l'hébergeur) En gros c'est DNS, à faire soi-même ou à déléguer, mais pas le choix d'avoir un TTL très court ... Si vous avez d'autres idées, faites vous plaisir ;) ++ Le mar. 3 mars 2020 à 13:06, Michel 'ic' Luczak a écrit : Hello, On 3 Mar 2020, at 11:15, Mickael Hubert wrote: Bonjour à tous, nous devons réaliser du HA (et si possible du loadbalancing) entre 2 instances HAProxy, ces 2 Haproxy doivent-être hébergés dans 2 DC différents. Pas possible de réaliser du VRRP car nous ne pouvons pas switcher l'IP publique de l'un à l'autre des DC. La solution la plus simple serait de réaliser du round robin DNS pour pointer sur les 2 IP publiques des 2 HAproxy. Mais avant de se lancer tête baissée dans le truc, je souhaitais savoir si vous auriez d'autre solutions à me proposer ? Je fais ça pour faire du “cdn lite” pour des clients avec du varnish sur 2 serveurs dédiés. Chacun porte aussi un gdnsd avec un healthcheck des deux serveurs. Les deux sont configurés comme NS du sous domaine “static.”. En situation normale, les deux renvoient l’IP des deux, si un des deux tombe (niveau varnish) pour une raison ou une autre, une seule IP est renvoyée. Si une des deux machines tombe complètement, un seul DNS fonctionne (c’est suffisant) et ne renvoie que l’IP de la survivante. ++ ic --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] HAProxy multi DC
Yep globalement deux options : GSLB (du pauvre ou pas, mais j'aime bien l'approche) ou anycast BGP. -- Raphael Mazelier On 03/03/2020 11:37, Thomas Pedoussaut wrote: Tu as la version DNSLB du pauvre, j'en ai fait depuis 2007. Ca utilise le fait que naturellement, la chaine de resolution DNS va chercher à trouver un NS up pour une zone. Soit ton site www.example.com Soit ta Machine A comme ip 1.2.3.4 Soit ta Machine B comme ip 5.6.7.8 Tu cree une sous zone lb.example.com Voici un extrait de ton fichier de zone: machineA IN A 1.2.3.4 machineB IN A 5.6.7.8 lb IN NS machineA lb IN NS machineB www IN CNAME www.lb.example.com. Et sur chacun des serveur tu fais aussi tourner un bind, chacun faisant autorité pour lb.example.com Et qui contient www 60 IN A 1.2.3.4 (sur la machineA) ou www 60 IN A 5.6.7.8 (sur la machine B) (pas de master/slave pour cette zone) Si les 2 serveurs fonctionnent, tu auras grosso modo du round robin. Si un serveur est down, immédiatement les client qui n'ont pas l'IP en cache seront tous sur l'instance encore UP. Au bout de 60 sec, les cache auront expiré et pareil tout le traffic arrivera sur la machine UP Il te reste a faire un mecanisme sur chaque serveur pour eteindre bind si ton haproxy (ou tous ses backend) est down pour ne plus servir la mauvaise IP. On 03/03/2020 11:15, Mickael Hubert wrote: Bonjour à tous, nous devons réaliser du HA (et si possible du loadbalancing) entre 2 instances HAProxy, ces 2 Haproxy doivent-être hébergés dans 2 DC différents. Pas possible de réaliser du VRRP car nous ne pouvons pas switcher l'IP publique de l'un à l'autre des DC. La solution la plus simple serait de réaliser du round robin DNS pour pointer sur les 2 IP publiques des 2 HAproxy. Mais avant de se lancer tête baissée dans le truc, je souhaitais savoir si vous auriez d'autre solutions à me proposer ? Car à ma connaissance, si un des HAProxy est HS, le DNS n'en saura rien et continuera à balancer du trafic dessus (avec 50% d'échec). Merci d'avance pour votre aide ! ++ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] le pétaoctet du pauvre
Concernant le hardware Maxime est un spécialiste ;) La bonne question : c'est que tu veux stocker dans tes 1Po ? et comment tu veux y accéder ? Sur ce genre de volumétrie j’éviterais le filer pur, je partirais plutôt sur du stockage objet (ceph, scality, openio). -- Raphael Mazelier On 29/02/2020 19:51, Michel Py wrote: Maxime De Berraly a écrit : Si tu a des DS4246 en trop je peut comprendre :D , mais sauf si c'est pour s'amuser pourquoi ne pas partir sur un storinator? https://www.45drives.com/ J'ai regardé avec beaucoup d'intérêt; vu de mon coté il y a 3 inconvénients majeurs : 1. C'est super profond; pour remplacer les disques il faut avoir les mégas rails avec les bras articulés pour les cables. 2. Impossible de remplacer les expanders SAS à chaud. Est-ce que çà fait le double-port SAS (multipath IO) ? 3. Ca chauffe. Les disques dans la dernière rangée, j'aimerais pas être à leur place. J'ai des MDS 600 : https://support.hpe.com/hpesc/public/docDisplay?docId=emr_na-c01671885 70 disques chacun, plein d'emmerdes. Mécaniquement c'est naze. J'ai aussi regardé çà : https://www.supermicro.com/en/products/chassis/4U/847/SC847E2C-R1K28JBOD Problème : single point of failure : l'expander SAS n'est pas remplaçable et la même carte fait les deux ports SAS. Michel 'ic' Luczak a écrit : https://github.com/ewwhite/zfs-ha/wiki J'ai regardé avec beaucoup d'intérêt aussi, au niveau hardware c'est l'idéal : tout est hot-swap. Inconvénient : il n'y a que NFS. Pas de iSCSI target ni de Samba :-( Phil Regnauld a écrit : Oui, ça marche, si on veut mettre tous ses oeufs dans un seul panier :) Le failover du stockage, c'est comme le failover de data center : çà marche des fois, des fois pas, faut tester souvent, et le jour ou t'en as vraiment besoin généralement il y a une surprise. C'est pas quand t'es dans la mouise qu'il faut commencer à regarder pourquoi pacemaker et corosync n'ont pas marché. En plus, le failover n'est pas immédiat, et il est plus que probable qu'il y a des trucs qui vont se planter. Je dis pas que çà sert à rien, mais faut que çà soit fait super bien. J'ai aussi regardé çà : https://www.synology.com/en-us/products/RC18015xs+ avec https://www.synology.com/en-us/products/RXD1215sas Problème : 1 seul port SAS qu'il faut cascader, en performance c'est nul. Le mettre dans son propre serveur c'est possible : https://xpenology.org/ Mais même s'il n'y avait pas l'aspect légal, c'est la galère avec les MAJ et le support. En fonction du besoin, fe ferais deux machines et du ZFS avec répliction croisées. Avec quel logiciel ? Si on veut vraiment 1 TO de stockage contigu/agregé, J'ai pas besoin de contigu. Un RAID60 / RAIDZ2 stripe de 300TO c'est suffisant pour moi. faut regarder CEPH plutôt J'ai regardé, pas encore essayé. Cà a l'air un peu usine à gaz sur les bords. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Bascule IP Publique
On 14/02/2020 04:55, Michel Py wrote: Je plussoie aussi. La redondance, c'est bien. La redondance testée, c'est mieux ! Quel que soit le système, çà marche rarement la première fois. J'ai presque envie de dire que même si cela a marché pendant le test cela ne marchera pas quand tu en auras besoin. La meilleure redondance d'infrastructure (réseau/système) c'est celle dont tu n'as pas besoin. Premièrement c'est toujours meilleur d'avoir une redondance pensé au niveau applicatif. Deuxièmement si je me fie à mes 18 ans d'expériences, finalement je pense qu'essayer de rendre les choses redondantes m'ont posé plus de problèmes et faire perdre de temps que sauver quoi ce soit. Le meilleur exemple, parmi les nombreuses anecdotes que je pourrais avoir sur le sujet, c'est la redondance de data-center, ou on essaye d'avoir tout en double équitablement réparti, et que finalement on double le spof, et que dès qu'un des deux DCs à un soucis, l'ensemble est HS. Testé et approuvé de nombreuse fois. Ceci étant je peux moduler ce propos, car en cas de crash majeur (type incendie ou autre) c'est tout de même beaucoup plus rapide de repartir de ton second datacenter. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Bascule IP Publique
Un lan étendu entre 2 dc(s) ce n'est pas le meilleur design que je conseillerais. Le mieux pour de la vrai redondance c'est du shared nothing, donc de la redondance avec un DNS externe. A défaut du L3, et une IP annoncée en BGP de l'un coté ou de l'autre. Ah oui c'est beaucoup mieux si possible d'avoir de l'actif/actif. Sinon le jour ou tu dois basculer tu peux être sur qu'il y a un détail qui fera que cela ne fonctionnera pas. -- Raphael Mazelier On 13/02/2020 20:34, Free wrote: Bonsoir, Pour ma part je te conseille effectivement d’utiliser du BGP pour la partie publique. Concernant la partie LAN, un niveau 2 entre les 2 DC serait le bienvenue (même plan d’adressage LAN sur les 2 DC du coup). Tu peux protéger ton infra par une HA entre deux firewalls, ton site A sera primaire et tu track des IPs/interface pour déclencher la bascule sur le FW secondaire et donc le 2e DC. Les 2 FW auront la même IP LAN (de ce que j’ai vu chez fortinet en tout cas) et donc pas de soucis de Gateway. Bonne soirée. Le 13 févr. 2020 à 19:07, Jean Théry a écrit : Clairement. Le 13/02/2020 à 19:06, David Ponzone a écrit : Pour moi, les 2 (LAN et WAN) sont nécessaires. C’est bien d’avoir uCARP ou truc pour bouger l’IP d’un serveur à l’autre entre les 2 DC, mais l’IP doit être joignable par les 2 transits. Tout en oubliant pas que les 2 machines/équipements doivent être sur le même domaine de broadcast/multicast (marrant le lien Wikipédia ne parle même pas de FreeBSD alors que le support existe depuis v9 :) Perso je conseillerai plutôt la solution BGP ici. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Bascule IP Publique
Comme proposé par mes collègues tu as la solution d'annoncer un /24 sur l'un ou l'autre des sites. Mais le meilleur serait à mon avis de ne pas avoir à le faire est d'assurer ta redondance niveau DNS. Cela dépend évidement du type de service que tu veux exposer (mais bon de nos jour tout est sur http(s) non ?). -- Raphael Mazelier On 13/02/2020 17:10, Bruno LEAL DE SOUSA wrote: Bonjour à tous, Je pose la question car je sais qu'ici y en a forcément qui l'ont déjà fait ou étudié :) On est actuellement en train d'étudier un projet Datacenter pour centraliser tous nos actifs en louant des racks chez un hébergeur. On aurait deux salles séparées par 50 Km. On fait arriver des liens internet dessus sur les deux salles. Mais comment basculer une IP publique d'une salle à une autre ? Le but est d'avoir deux salles extrêmement identiques et de basculer de l'une à l'autre en toute transparence. Quelles sont les solutions possibles dans ces cas là ? IP Publique virtuelle ? Interfaçage de mes routeurs avec ceux des opérateurs ? Merci pour vos retours ! A+ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Nouvelle Livebox sans SFP ?
Il faudrait faire de l’agrégation over the box. C'est possible mais cela n'a aucun intérêt. Enfin d'une manière générale je ne comprends même pas le point d'avoir plus de 1gbit/s @home. -- Raphael Mazelier On 29/01/2020 12:28, Romain wrote: Il y a 2 Gbps au cul de la box mais que des ports 1 Gbps et pas de support de l'agrégation. Y'a un topic ici : https://lafibre.info/orange-les-news/livebox-5-2-gbs-sur-un-seul-pc/ Le mer. 29 janv. 2020 à 12:25, Richard Klein a écrit : Bonjour Le nom de code était Ankaa pour la phase beta Pas pu testé les 2G mais il parait que c'est 2G par agrégation de deux port lan 1G Richard Le mer. 29 janv. 2020 à 12:17, Module Fibre < aurelien.rina...@modulefibre.com> a écrit : Bonjour David, Oui je confirme, un technicien Orange me l'a confirmé la semaine dernière Aurélien *Aurélien Rinald**i* aurelien.rina...@modulefibre.com *Directeur associé / Module Fibre* 15 avenue de Norvège / ZA Courtaboeuf 91140 Villebon sur Yvette 06.22.53.15.87 *www.modulefibre.fr <http://www.modulefibre.fr>* Retrouvez nous au *Cloud Datacenter* le 18/19 mars 2020 à Portes de Versailles https://www.datacenter-cloud.com Le mer. 29 janv. 2020 à 12:13, David Ponzone a écrit : FRnOGien.ne.s, On me dit qu’Orange aurait commencé à déployer des nouvelles box sans ONT et sans SFP (donc connecteur fibre en dur et non-extractible). C’est vrai ou on m’a bullshité ? Si oui, c’est une mauvaise nouvelle (surtout pour ceux qui achètent du Just Fibre, parce que ça va être Just Fibre et Box). Merci --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] OSPF Bird et configure
Personnellement j'injecterais ces routes en BGP (via exabgp ou autre). Pas besoin de reloader quoi que ce soit coté Bird. (Btw je migrerais tes 8k routes ospf dans ibgp) -- Raphael Mazelier On 16/01/2020 18:03, Duchet Rémy wrote: L'objectif c'est justement que Bird apprenne les routes via autre chose que "STATIC". Aujourd'hui c'est un script qui modifie un simple fichier, via de l'automatisation. Et c'est STATIC => OSPF . Mais dans ce sens pour ajouter une route dans la table STATIC, ça demande le "configure" pour que la route soit active pour Bird. Et donc le changement de la table STATIC provoque la propagation de l'intégralité de la table OSPF à tous les autres devices. Pour la partie BGP je n'ai pas de soucis, d'autant que c'est un de nos RS. Par contre, dans la 2.0.7 Ipv4 et IPv6 c'est le même process. Et c'est les TABLE qui semblent séparer les versions, du coup toute la config change. Cordialement, Rémy -Original Message- From: Alarig Le Lay Sent: jeudi, 16 janvier 2020 17:49 To: Duchet Rémy Cc: frnog@frnog.org Subject: Re: [FRnOG] [TECH] OSPF Bird et configure What ?! bird> show route Table master4: 0.0.0.0/0unicast [kernel_ipv4 09:46:49.133] (10) via 85.166.184.1 on enp2s0 45.91.126.32/28 unicast [ospf_ipv4 09:47:05.225] E1 (150/20) [45.91.126.96] via 45.91.126.96 on enp3s0.50 79.170.80.128/25 unicast [ospf_ipv4 10:10:59.225] E2 (150/10/64) [4faa50fa] [45.91.126.236] via 45.91.126.236 on tinc0 […] bird> show route protocol kernel_ipv4 Table master4: 0.0.0.0/0unicast [kernel_ipv4 09:46:49.133] (10) via 85.166.184.1 on enp2s0 85.166.184.0/22 unicast [kernel_ipv4 09:46:49.133] (10) dev enp2s0 bird> show route protocol kernel_ipv6 Table master6: ::/0 unicast [kernel_ipv6 09:46:49.133] (10) via fe80::5e5e:abff:fe43:1ece on enp2s0 2001:4640:a14f::/48 unreachable [kernel_ipv6 09:46:49.133] (10) J’ai bien des routes OSPF et bird ne les apprend pas via le kernel. Je ne vois pas comment ça pourrait marcher s’il le faisait d’ailleurs. Et en version BGP (avec une full) c’est pareil : bird> show route 128.0.128.0/20 via 89.234.186.33 on vmbr12 [ibgp_asbr01_ipv4 2020-01-04] * (100/?) [AS25513i] via 89.234.186.33 on vmbr12 [ibgp_asbr02_ipv4 2020-01-11 from 89.234.186.34] (100/?) [AS25513i] 208.0.208.0/24 via 89.234.186.34 on vmbr12 [ibgp_asbr02_ipv4 2020-01-11] * (100/20) [AS46559i] via 89.234.186.34 on vmbr12 [ibgp_asbr01_ipv4 2020-01-11 from 89.234.186.33] (100/20) [AS46559i] 40.0.40.0/24 via 89.234.186.34 on vmbr12 [ibgp_asbr02_ipv4 2020-01-11] * (100/20) [AS4249i] via 89.234.186.34 on vmbr12 [ibgp_asbr01_ipv4 2020-01-11 from 89.234.186.33] (100/20) [AS4249i] […] bird> show route protocol kernel1 89.234.186.114/32 dev tap109i0 [kernel1 2019-09-29] * (10) 89.234.186.115/32 dev tap106i0 [kernel1 2019-09-29] * (10) 80.67.190.218/32 dev tap140i0 [kernel1 2019-09-29] * (10) […] Et ça correspond bien aux routes que j’exporte : bird> show route export ibgp_asbr01_ipv4 89.234.186.114/32 dev tap109i0 [kernel1 2019-09-29] * (10) 89.234.186.115/32 dev tap106i0 [kernel1 2019-09-29] * (10) 80.67.190.218/32 dev tap140i0 [kernel1 2019-09-29] * (10) 89.234.186.112/32 dev tap101i0 [kernel1 2019-09-29] * (10) […] Et là, c’est du 1.6 (merci debian…) On jeu. 16 janv. 16:28:36 2020, Duchet Rémy wrote: En fait les routes BGP apparaissaient dans le kernel avec les routes OSPF. En lisant le mail, je viens de relire la config de Bird. Je viens de me rendre compte que j'avais un export all sous le protocol kernel qui me polluait. Du coup, je regarde pour upgrader en 2.0.7, pour loader les routes (dans l'idée linux => kernel => annonce bgp) et ainsi supprimer l'OSPF. Mais bien évidement la migration 1.6 => 2 se fait dans la ré-écriture complète de la conf. Merci à tous pour les réponses. Rémy -Original Message- From: frnog-requ...@frnog.org On Behalf Of Alarig Le Lay Sent: jeudi, 16 janvier 2020 09:41 To: Duchet Rémy Cc: frnog@frnog.org Subject: Re: [FRnOG] [TECH] OSPF Bird et configure Non, tu connais seulement les routes qui sont insérées « à la main » (ou via un autre soft). Sinon bird apprendrait ses propres routes et bonjour la boucle infinie. On jeu. 16 janv. 08:08:22 2020, Duchet Rémy wrote: Bonjour, Sur cette même instance Bird, on a déjà du BGP pour agréger plusieurs full view. Du coup, le kernel connaissant déjà toutes les routes BGP, ça va faire mal de chercher à voir si une route OSPF est déjà dans la table.. Mais oui, une des pistes est de basculer sur du "tout" BGP. Mais la problèmatique sera identique si on doit faire du configure pour ajouter des routes. Cordialement, Rémy -Original Message- From: frnog-requ...@frnog.org On Behalf Of Alarig Le Lay Sent: mercredi, 15 janvier 2020 20:24
Re: [FRnOG] [TECH] Admin Outofband or not
On 15/01/2020 14:48, Guillaume Genty (Waycom) wrote: Hello, Si tu veux quelques conseils en OOB que on a identifié au fil du temps chez nous: - Avoir les consoles de tous les équipements critiques en OOB (genre pour avoir le rommon cisco qui reboot pas) Oui je n'ai pas préciser mais OOB pour moi c'était uniquement des routeurs console. - Éviter au max le L2 ou L3 entre la prod et l'OOB. (un broadcast storm pourrait te planter ton routeur OOB) Règle numéro un de l'OOB aucun lien, mais vraiment aucun lien avec ton réseau. - Pour les équipements avec un port de management L3 IP (genre ASR) mettre un bête switch premier prix pour ne pas utiliser le L2 de prod Je ne suis pas pour connecter les cartes de managements à l'OOB. Un hébergeur a connu un incident marrant par exemple; broadcast storm sur son réseau Admin/OOB, interface de management d'une certaine marque commençant par J connectée, trafic qui remontent aux CPUs des control plane. Plouf. - Si tu met des restrictions IP, prévoit une VM de rebond à l'extérieur de ton réseau, elle même accessible depuis n'importe quelle IP +1. - Des connexions grand public 4G ou de l'ADSL (pour les sites où ça ne captent pas) sont largement suffisantes, par-contre prévoit un tunnel qui remonte sur ta VM de rebond - Supervise tes équipements de OOB !!! Je pense même que c'est le point le plus important de la liste ! +100 Avec tout ça, tu devrais être tranquille un moment... --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Admin Outofband or not
Hello, Ce qui reste certain c'est qu'il te faut un OOB sur chaque site. Sur un nombre restreint de pop (moins de 20 disons) et des pops connus, je trouvais toujours à m'arranger avec des amis pour avoir un accès L3 depuis un autre AS. On déployait de l'opengear avec restrictions IP et clé ssh (on estimait que c'était suffisant comme sécu). On supervisait à minima ces équipements (ping , probe ssh). Maintenant sur des pops plus exotiques il faut souvent demander au DCs, ou au pire faire du reverse vpn 4g. -- Raphael Mazelier On 15/01/2020 13:00, FAGART, Thomas wrote: Bonjour la liste, Suite à des incidents récents un peu durailles sur nos réseaux, on se repose un peu la question de plus développer notre réseau out of band. Finalement nous sommes un peu jeune là-dessus, on a fait quelques tentatives listées ci-dessous : -Outofband « interconnecté » avec l'IGP via de l'ADSL Tiers + VPN sur des pops importants -Outofband en mode console only sur des sites de transmission critiques via de la 3G/4G Tiers + VPN Les difficultés qu'on a rencontrées ou qui me viennent en tête sont les suivantes : -Comme l'outofband n'était pas considéré comme critique, la sup ne l'était pas nécessairement non plus et le jour où on en besoin, ben ça ne fonctionne plus -> surtout une question de process -L'outofband passant par du tiers en L3 c'est aussi bien souvent une fenêtre sur des pops importants et des équipements importants qu'il est plus compliqué de sécuriser Du coup mes questions : -Comment faites-vous chez vous ? (si c'est pas indiscret :) ) -Quels sont vos conseils ? Merci Thomas -- Les donnees et renseignements contenus dans ce message sont personnels, confidentiels et secrets. Toute publication, utilisation ou diffusion, meme partielle, doit etre autorisee. Si vous n'etes pas le bon destinataire, nous vous demandons de ne pas lire, copier, utiliser ou divulguer cette communication. Nous vous prions de notifier cette erreur a l'expediteur et d'effacer immediatement cette communication de votre systeme. Any data and information contained in this electronic mail is personal, confidential and secret. Any total or partial publication, use or distribution must be authorized. If you are not the right addressee, we ask you not to read, copy, use or disclose this communication. Please notify this error to the sender and erase at once this communication from your system. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [MISC] RE: [FRnOG] [MISC] Idée de sujet de mémoire d'ingénieur?
On 14/01/2020 11:21, Laurent GUINCHARD wrote: "IP/MPLS Vs EVPN en environnement data-center" Ou BGP dans le data-center et les réseaux de clos ? -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] port down malgré niveau optique correcte
Il existe plein de raisons pour lesquelles un port avec une connectivité L1 peut être down. En général il faut regarder au niveau protocolaire l2 (stp, auto-neg, etc..) Cdt, -- Raphael Mazelier On 09/01/2020 10:24, Alexis Lameire wrote: si c'est de l'arista, il faut souvent passer un speed forced 10fgfull sur l'interface Cordialement Alexis Lameire --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] plusieurs routers bgp problème avec igp
On 26/12/2019 19:46, Alarig Le Lay wrote: Perso j’aime pas le next-hop self, c’est un coup à faire passer trois switches à un paquet alors qu’un autre routeur peut être juste à côté. Je considère que mes intercos font partie de ma topologie, donc je les mets dans mon OSPF. Cela peut être complètement légitime de faire le tour de ton backbone pour aller au routeur d'à coté. Tu dois maîtriser ta topologie avec les poids qui vont bien sur tes liens d'interco. Si tu ne fait pas ça tu vas toujours au plus prêt. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] plusieurs routers bgp problème avec igp
On 26/12/2019 12:33, Paul Rolland (ポール・ロラン) wrote: Peut-être pour te contraindre à TOUJOURS monter tes sessions BGP sur les Loopback. Peut-etre aussi parce que ca t'oblige a regler d'abord tes problemes de NLRI ;) Parce que selon moi c'est le plus propre et lisible. Un IGP ne servant qu'à faire du calcul de topologie tu n'as donc que ta topologie dedans. Et effectivement cela t'oblige à faire du next-hop self sur tes sessions iBGP ce qui me semble une bonne pratique, sinon tu as vite fait de l'oublier et d'avoir des routes avec des NH qui pointe sur des IPs d'intercos. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] plusieurs routers bgp problème avec igp
On 26/12/2019 11:01, Antoine DURAND wrote: Merci David :) Je viens de comprendre mon erreur et effectivement c'est tout bon, je n'ai plus de rib-failure !!! Est-ce que sur les interfaces qui sont côtés transitaires ou qui ne sont pas dans le igp je dois indiquer à OSPF de les passer passive (passive-interface FastEthernetX/X) ? A titre personnel je le ferais. Pour moi IGP ce n'est activé que sur les interfaces dites "Core/Interco" de ton backbone. Cdt, -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] plusieurs routers bgp problème avec igp
On 26/12/2019 09:31, David Ponzone wrote: Donc la seule chose que tu dois redistribuer dans OSPF, c’est les connected: A titre personnel je ne mettrais que les loopbacks. Il y a un micro débat sur mettre les subnets d'interco core. (tiens pourquoi ne parle d'ISIS quand on parle IGP ?) La seule chose que tu dois redistribuer dans BGP, c’est tes statiques (à priori): Tout le reste que tu veux joindre non ? donc tes connected (clients), statiques, BGP customers, etc... -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] TCP shape depuis les US - Identifier l'origine ?
On 12/12/2019 10:19, Frederic Dumas wrote: C'est une question de curiosité, pas un problème réel dans le cas présent. En général le rtt (et donc la vitesse de la lumière), et le loss sont une bonne indication du débit théorique que tu peux atteindre en TCP ,;) -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Grève : blackout en datacenter?
On 11/12/2019 14:50, Hervé BRY wrote: Certains sont qualifiés "Opérateur d'Importance Vitale", mais je ne sais pas ce que ça implique vraiment en cas de crise... J'imagine qu'il ne sont pas soumis au délestage en cas de gros problème d’approvisionnement électrique et qu'il n'est pas non plus possible de pas manuellement arrêter leur distribution sous peine de sanction légale ? -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] BGP best practice
On 11/12/2019 08:36, Antoine DURAND wrote: Hello, Période calme pour moi avant les fêtes, je me remets sur la refonte de mon archi BGP... Est-ce que vous supprimez la route par défaut 0.0.0.0/0 de vos routeurs BGP lorsque vous êtes en full-view ? Il y a deux choses : accepter une route par défaut de tes transits (ça se discute) et avoir une default dans ta table. J'avais l'habitude de garder une default statique vers l'un de mes transits sur mes edge, comme çà en cas de grosse foirade tes paquets peuvent quand même sortir, et tu peux te connecter sur ton edge sur l'ip d'une de tes intercos. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Besoin d'avis pour mon avenir professionnel
Bonjour, Sur ce sujet hautement inflammable je me permets de donner mon expérience et mon petit avis/conseil. Pour le contexte : j'ai l’équivalent d'un master2 en Ingénierie Réseau et Système, donc la fac (UVSQ), ayant auparavant eu un DUT informatique (à Nantes). Il faut savoir que j'avais choisi de faire un DUT (cycle court) car je m'ennuyais profondément en cours au lycée, et que je ne voulais pas partir en prépa. Je ne regrette pas du tout ce choix, bien au contraire. J'estime que mes années d'études font partie des meilleurs moments de ma vie. La 1ere partie, l'IUT n'était pas fou en terme d'enseignement mais 1) j'ai appris énormément avec mes collègues et je n'en serais clairement pas la ou j'en suis si je ne les avais pas rencontré 2) j'ai profité des ces années pour me découvrir (aka faire des expériences, la fête mais pas que). Si tu peux financièrement le faire ne te prive pas de ses années. La 2eme partie : la fac + dess auront été fondamentales pour moi en terme d'apprentissage. J'ai eu la chance de revenir sur la théorie de toutes les notions pratiques que nous avions survolé en IUT. J'ai adoré même si clairement je n'utilise pas tout ce que j'ai appris. Mais cela m'a donné les bases théoriques nécessaires pour voir plus loin que le bout de mon nez, et l'envie de repousser les limites (les limites/boundaries en entreprise je pourrais en parler longuement). Évidement tout le monde est différent, et je connais des autodidactes qui sont maintenant CTO, ou qui s'éclatent dans des supports postes. Je pense toutefois que c'est plus dur, pas sans diplôme (je crois que les sociétés ne font plus trop attention à ca maintenant) mais sans ce bagage théorique. Tu peux l’acquérir après, mais dés que tu bosses tu es forcément sur un domaine spécifique, et le soir tu auras peut être plus de mal à t'autoformer. Maintenant si ça te saoule et que tu as envie de toute défoncer en entreprise => go. L'essentiel c'est de garder cette soif d'apprentissage constant. My 2cents. -- Raphael Mazelier -Message d'origine- De : Cécile MORANGE Envoyé : dimanche 17 novembre 2019 22:10 À : frnog-m...@frnog.org Objet : [FRnOG] [MISC] Besoin d'avis pour mon avenir professionnel Hello la liste ! Avant de me lancer dans une aventure pour le moins risqué (= quitter ma formation actuelle et aller faire un vrai métier qui me plait), j’aimerais avoir votre avis, vous qui travaillez dans ce secteur d’activité et vous qui savez la réalité des choses. Pour ceux qui ne me connaissent pas, Cécile, 19 ans, Aix-en-Provence, en alternance BTS SIO SISR (en gros système réseau) chez un OIV. Mon CV est disponible ici : https://cecilemorange.fr. @AtaxyaNetwork sur twitter (oui oui, la folle qui a fait une server room chez elle). Ma question est la suivante : - Si je quitte mon BTS maintenant, aurai-je des chances de trouver un boulot qui me plait ? (Le pourquoi du comment se trouve ici : https://www.twitlonger.com/show/n_1sr2c32. En résumé, j’ai l’impression de rien apprendre en cours, et mon travail consiste à 90% à faire des tickets) J’en ai parlé avec plusieurs personnes dans cette liste, on a déjà débattu sur le « Oui, mais un diplôme c’est mieux », mais dans l’état actuel des choses, la seule chose qui me freine à arrêter ce BTS et l’alternance est de ne pas retrouver de travail. Un boulot qui me plairait ? De la technique. (bon, plus en système qu’en réseau), c’est-à-dire toucher à des serveurs, des configs, et pas faire des tickets pour que ce soit l’infogérant qui le fasse. Et un qui me fait rêver ? En datacenter. Voilà, j’ai besoin de vos avis (et des idées de métier que je pourrais viser) pour m’aider dans ma décision finale Merci d’avance et bonne fin de week-end à tous (ou bon lundi, ça dépends de quand vous lirez ce mail !) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] changement hardware et choix Quagga/FRRouting
On 14/11/2019 20:05, Alarig Le Lay wrote: On jeu. 14 nov. 18:16:34 2019, Antoine DURAND wrote: Je l’active pour BCP38 et autres trucs du genre, mais toujours sur des trucs en stateless ; et je ne fais pas du tout de NAT. Yes soit tu te passes complètement d'iptables sur tes routeurs linux (c'est complètement faisable avec un peu de config ip et des tables). Soit tu fais au pire du stateless. Activer iptables même en stateless est coûteux, en statefull c'est l'échec. Encore une belle différence avec un routeur qui peut gérer ça en hardware. Après je ne connais pas le statut dans dpdk. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] changement hardware et choix Quagga/FRRouting
On 13/11/2019 15:44, Alarig Le Lay wrote: Et quand on a compris la logique, on ne veut pas retourner sur du cisco like :p Sérieusement, des gens *aiment* la CLI de IOS ou IOS-XE ? Disons que la CLI cisco est un standard de facto et qu'elle est plutôt simple et concise à lire. En revanche j'ai toujours détesté l’édition (bon avec un commit mode ça passe un peu mieux, style sur nxos ou sur ios-xr). Pire encore sont les access-list et les route-map. Une configuration juniper ou bird sera plus verbeuse mais beaucoup plus flexible et simple à changer. Cdt, -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] changement hardware et choix Quagga/FRRouting
On 13/11/2019 11:10, Jérôme Nicolle wrote: Le projet a forké depuis quelques années déjà, et c'est de loin le plus actif. C'est donc préférable de partir sur FRR plutôt que Quagga. C'est un retour source en quelque sorte :) BIRD est aussi un excellent choix, plus simple à automatiser que FRR à mon avis, mais il n'a rien à voir en terme de CLI. Bird est beaucoup plus flexible au prix d'une certaine courbe d'apprentissage. Je préfère personnellement mais je peux comprendre l'approche CLI cisco like. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Multihoming BGP avec COGENT en principal et SFR en backup
oui et je mentirais si je disais ne jamais l'avoir fait. -- Raphael Mazelier On 09/11/2019 01:44, Guillaume Barrot wrote: ou de monter un GRE ... Le jeu. 7 nov. 2019 à 14:35, Raphael Mazelier a écrit : --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Multihoming BGP avec COGENT en principal et SFR en backup
On 07/11/2019 14:24, Emmanuel DECAEN wrote: 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... Le volume principalement. (taille des tuyaux et société) 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é. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
