Re: [FRnOG] [TECH] Hmm GPON Kosc, étanche, vraiment ?
Ah mais c'est dans la session pppoe. Ok c'est n'importe quoi mais différent. -- Raphael Mazelier On 01/06/2022 09:15, Jérôme Marteaux wrote: J'ai un lien dans le lot, je confirme, le CPE reçoit des paquets dans la session PPPoE qui ne sont pas pour lui et le pire c'est qu'il les traite car ils ont tout l'air d'être correct. Incroyable ! Quel bug ! Jérôme --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Hmm GPON Kosc, étanche, vraiment ?
Alors déjà que tu puisse voir le trafic downstream des autres clients c'est étrange. Mais soit admettons les datas sont la à ta porte donc si le trafic est en clair et que l'ont se met en mode sniffing (ca doit exister) pourquoi pas. Mais alors l'upstream alors la je vois même pas comment c'est possible. Si tu vois l'upstream cela veut dire que tu l'as d'abord reçu pour le renvoyer ?! une sorte de bounce. Mais ca doit créer un bazar pas possible. En tout cas c'est plutôt rigolo et intéressant si tu as le fin mot de l'histoire. (ça sent quand même la méga mauvaise config coté kosc) -- Raphael Mazelier On 31/05/2022 17:29, David Ponzone wrote: Chez un client je vois le traffic descendant des autres mais chez un autre client, je vois le traffic montant des autres. Et ça c’est plus embêtant, parce qu’en GPON, les splitters sont filtrants dans le sens montant, donc c’est pas possible, sauf si c’est l’OLT qui renvoie le traffic up->down. Bref, encore beaucoup de zones d’ombre, et je suis presque sûr que la correction ne va pas venir avec une belle explication transparente :) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Hmm GPON Kosc, étanche, vraiment ?
Les spécialistes du GPON me corrigeront mais il me semble que le chiffrage peut être optionnel (même si c'est vivement déconseillé) Cela n’empêche pas l'ont de faire le tri entre ce qui le concerne ou pas (via un id, le pcbd je crois). Donc pas de risque de saturer le lien entre l'ont et le cpe normalement. Je suis quand même surpris que tu puisse passé l'ONT capturer des paquets qui ne te sont pas destiné (sauf s'ils sont mal catégorisé upstream) -- Raphael Mazelier On 31/05/2022 16:44, David Ponzone wrote: Ok donc la sélection du traffic qui concerne le CPE ne repose que sur le cryptage (coucou Gary), parce que effectivement, et merci pour la correction, dans le sens descendant, il n’y a qu’un émetteur donc pas de problème de collision, donc pas besoin de TDM. Si c’est donc bien ça qui déconne sur certains OLT Altitude, je suis quand même surpris par le peu de traffic que je reçois pour les autres clients, mais néanmoins quasi-permanent (c’est comme un bruit de fond de 500Kbps, ça ressemble pas du tout à du traffic Internet habituel). Ca veut aussi dire que si le traffic est en clair, il peut saturer la capa du port 1G entre l’ONT et le CPE de tous les clients sur le PON. Rien que pour cette raison, cela ne devrait pas être optionnel, sauf peut-être pour des tests. Le 31 mai 2022 à 16:19, Patrick Chollat a écrit : Dans la technologie GPON tous les ONT d'un PON reçoivent le trafic de tous les ONT du PON dans le sens descendant ,d'où la nécessité de l'encryptage. Le TDMA n'est utilisé que dans le sens montant. Le mar. 31 mai 2022 à 16:09, David Ponzone mailto:david.ponz...@gmail.com>> a écrit : Que le traffic ne soit pas crypté ne signifie pas que tous les ONT le forwardent vers le CPE. Sinon je vois mal comment le CPE du client va faire pour gérer sur son port 1G un max de 2.4Gbps de traffic dont une grrrande partie n’est pas pour lui. Ca serait pathétique de la part de la techno. L’ONT est censé faire une extraction TDM il me semble, avec décryptage optionnel. Le 31 mai 2022 à 16:01, Benoît Grangé mailto:benoit.gra...@gmail.com>> a écrit : Bonjour, dans beaucoup de technologies réseau que connaît on à le choix de définir les algo de chiffrement utilisées, le premier niveau étant "None". J'ai déjà vu des déploiements ou c'était le cas ;-) et c'est peut être ce que vous observez. --- Liste de diffusion du FRnOG http://www.frnog.org/ <http://www.frnog.org/> --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [JOBS] spécialisation
La suite car c'est parie trop vite : - niveau système : sans jugement sur le fond donc. On constate que le marché sur le onprem/stockage se réduit puisque de nombreuse société se tournent sur les cloud publics. Et il y a 2/3 technos buzzword à la mode que tu permettrons d’être "bankable" sur la marché. Ce qui est beaucoup recherché donc en ce moment ce sont des SREs (whatever ce que cela veut dire pour les sociétés). Des personnes qui connaissent donc au moins un cloud public (honnêtement ce n'est pas difficile à appréhender si tu as fait du on-prem avant), avec la maîtrise de technologie d'Iac (sic) comme terraform, de ci/cd, et grosse hype du moment Kubernetes. Je ne pense pas que cela soit mauvais d'apprendre ces technos (même si personnellement ce n'est pas des choses que je trouve passionnante). PS : "devops" ce n'est pas censé être un métier, mais comme on tord tout, on associe en général cela à des personnes qui sont la pour faciliter l'expérience des développeur (d'ailleurs maintenant on parle d’équipe developpers experience et tooling/platform). C'est souvent des postes ou l'on demande de faire de la CI/CD et d'aider / faire du support pour le déploiement des devs avec les technos sus nommés. En espérant t'avoir aider (ou à minima ne pas t'avoir plus embrouillé) -- Raphael Mazelier On 26/05/2022 20:53, Raphael Mazelier wrote: Bonsoir, Je vais risquer une réponse. (ce n'est que mon avis et il n'a aucunement prétention à être une vérité quelconque, et se base sur mon expérience personnelle qui n'est évidement pas celle des autres.) Premièrement c'est difficile de te répondre car je ne te connais pas, je ne sait donc pas évaluer ton niveau technique, dans le sens tes bases et capacités d'apprentissage ; ce qui pour moi est un des paramètres à prendre en compte dans ta réflexion. Idéalement et intellectuellement parlant je pense que l'ultra spécialisation est une erreur sur le long terme dans notre discipline. J'ai envie de penser que nous sommes tous des ingénieurs en science informatique, et que tout sous domaines / technologies doit pouvoir s'apprendre relativement aisément et rapidement. Maintenant il existe tout de même des grands domaines qui sont relativement vastes et qui demandent des dizaines d'années d'expérience avant d’être vraiment compétent / autonome. Je vois : - l'ingénierie logicielle- l'ingénierie des opérations : système/infrastructure et réseaux. Je dirais même que l’ingénierie réseau est un domaine à part entière (même si je connais certains qui peuvent évoluer dans les deux milieux, j'ai même la prétention d'en faire partie) Idéalement toujours, tu pourrais donc choisir un projet d'entreprise qui te plaît et y aller, en apprenant ce qu'il y a apprendre pour ce travail. Donc rester généraliste dans un des ces gros domaine. Maintenant je sais que nous sommes pas tous égaux devant l'apprentissage, ni le temps que nous souhaitons dépenser dans notre travail (passion pour moi donc c'est beaucoup plus simple). La réponse plus pragmatique de l'état du marché tel que je le vois : - les bases et la théories seront toujours utiles - le réseau reste un marché de niche, domaine très intéressant et plutôt bien payé. mais petit. - niveau systeme : sans jugement sur le fond. >> la suite On 26/05/2022 15:39, luc le rumeur wrote: Bonjour, Petite bouteille à la mer, la 40aine approche... Après 10 ans dans l'it, dont les 5 dernière à faire de l'adminsys je demande vers où aller. En gros je suis "intermédiaire" dans les facilities datacenter, le compute/storage/network/l'archi on premises. Au vu du marché est ce que ça vous semble plus pertinent de : - de me spécialiser dans un domaine si dessus - apprendre l'infra "cloud" - faire du DevOps ayant un passé de dev. - rester généraliste Tout commentaire est le bienvenu, on est pas vendredi :-) Merci de votre temps ! --- 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] [JOBS] spécialisation
Bonsoir, Je vais risquer une réponse. (ce n'est que mon avis et il n'a aucunement prétention à être une vérité quelconque, et se base sur mon expérience personnelle qui n'est évidement pas celle des autres.) Premièrement c'est difficile de te répondre car je ne te connais pas, je ne sait donc pas évaluer ton niveau technique, dans le sens tes bases et capacités d'apprentissage ; ce qui pour moi est un des paramètres à prendre en compte dans ta réflexion. Idéalement et intellectuellement parlant je pense que l'ultra spécialisation est une erreur sur le long terme dans notre discipline. J'ai envie de penser que nous sommes tous des ingénieurs en science informatique, et que tout sous domaines / technologies doit pouvoir s'apprendre relativement aisément et rapidement. Maintenant il existe tout de même des grands domaines qui sont relativement vastes et qui demandent des dizaines d'années d'expérience avant d’être vraiment compétent / autonome. Je vois : - l'ingénierie logicielle- l'ingénierie des opérations : système/infrastructure et réseaux. Je dirais même que l’ingénierie réseau est un domaine à part entière (même si je connais certains qui peuvent évoluer dans les deux milieux, j'ai même la prétention d'en faire partie) Idéalement toujours, tu pourrais donc choisir un projet d'entreprise qui te plaît et y aller, en apprenant ce qu'il y a apprendre pour ce travail. Donc rester généraliste dans un des ces gros domaine. Maintenant je sais que nous sommes pas tous égaux devant l'apprentissage, ni le temps que nous souhaitons dépenser dans notre travail (passion pour moi donc c'est beaucoup plus simple). La réponse plus pragmatique de l'état du marché tel que je le vois : - les bases et la théories seront toujours utiles - le réseau reste un marché de niche, domaine très intéressant et plutôt bien payé. mais petit. - niveau systeme : sans jugement sur le fond. On 26/05/2022 15:39, luc le rumeur wrote: Bonjour, Petite bouteille à la mer, la 40aine approche... Après 10 ans dans l'it, dont les 5 dernière à faire de l'adminsys je demande vers où aller. En gros je suis "intermédiaire" dans les facilities datacenter, le compute/storage/network/l'archi on premises. Au vu du marché est ce que ça vous semble plus pertinent de : - de me spécialiser dans un domaine si dessus - apprendre l'infra "cloud" - faire du DevOps ayant un passé de dev. - rester généraliste Tout commentaire est le bienvenu, on est pas vendredi :-) Merci de votre temps ! --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [ALERT] Nombreuses coupures de fibres optiques en France
Là, par contre, je ne vois pas comment un paquet qui fait Ajaccio-Ajaccio pourrait consommer plus de CO2 que le même paquet qui monte à Paris, fait un petit tour sur le périph' optique, puis redescend. J'ai même eu des cas où çà passait... par la Nouvelle-Zélande ! Quoique, connaissant bien nos amis les marketeux écolo-bobo, ils devraient arriver à nous démontrer le contraire :-) Pourtant je pense que le coût de transport de ton paquet est marginal par rapport au coût de ton équipement, sans parler du footprint de rajouter des petits datacenter un peu partout. Je suis persuadé que purement écologiquement parlant la centralisation peut être meilleure. En attendant, les opérateurs n'ont pas vraiment intérêt à ce que çà change, puisqu'ils me facturent deux fois un transit aller/retour à Paris :-) ?! Moi, la question que je me pose, c'est pour le téléphone : quand le cuivre aura disparu, et que tout sera en ToIP, cela veut dire que si les fibres sont coupées à Montsouris, je ne pourrai plus commander ma pizza à la paillote du coin ? ;-) C'est déjà le cas rassure toi. Le cuivre ne subsiste que jusqu'au premier point de mutu. -- Il y a peut-être un juste milieu entre les deux, non ? Je pense qu'il faut revoir les mentalités dans la conception d'ensemble des réseaux. Par exemple en organisant le coeur de réseau autour de deux ou 3 plaques régionales (Marseille ? Toulouse ?) et en décentralisant beaucoup plus. Moi, je suis un insulaire, donc j'ai naturellement cette réflexion dite d'autonomie, que certains ont tendance à monter en épingle politique, mais qui est simplement une logique de territoire, qui veut que l'on consomme ce que l'on produit localement, et que l'on élimine nos déchets tout aussi localement. Je vois de plus en plus d'initiatives de data centers régionaux/locaux, mais çà reste à la marge par rapport à un TH2 ou un PA3. Je pense que si tout le monde prenait un peu plus en compte les scénarios de perte des gros DC Parisiens (OVH nous a prouvé que çà peut se produire par accident/négligence, et ces derniers jours nous montrent que les malandrins commencent à s'intéresser à ces cibles très vulnérables), la logique de territoire prendrait certainement un peu plus de sens... Oui ca ok. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Nombreuses coupures de fibres optiques en France
On 28/04/2022 16:50, Clement Cavadore wrote: Good point ! Indeed very good point! -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Nombreuses coupures de fibres optiques en France
On 28/04/2022 15:55, Rod Beck wrote: In any country where one city dominates like Paris in France or London in the UK, it is likely that networks will be vulnerable because economics will push a lot of infrastructure into that dominant city. That central city become a major traffic hub. My opinion too. The only country that have a very different situation is actually USA, but more because of the inner nature of the country, and because of its width, that they have multiple big hubs. That said put north virgiania down and we will laugh... (well no). -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Nombreuses coupures de fibres optiques en France
Quelques commentaires la discussion autour de la centralisation des infrastructures internet en France. Premièrement oui nous savons tous que l'infrastructure fibre est relativement fragile, sauf qu'en réalité si on prend du recul sur l'incident, nous avons à faire à un acte de malveillance cordonnée et plutôt bien préparé à priori. Hors est ce que l'internet Français est HS ? loin loin de la. Il y a eu coupures sur une parties des abonnées de certains FAIs localisées et pour ceux qui utilisaient ces chemins de fibre sans gros contournement. Vous dites que l'internet à été conçu pour être résilient. Mais c'est complètement le cas ; mais à l’échelle macro ! L'internet n'a pas été conçu pour être résilient au niveau last miles. De plus certains l'ont mentionné à raison, l'internet FR fonctionne à 95% en mode minitel, de l'abonné pour aller chercher du contenu qui est centralisé (en France à Paris). Donc vouloir des peerings régionaux c'est bien, je ne vais certainement pas cracher dessus... mais est ce réellement utile ? De plus rajouter des points de peerings un peu partout cela à un coût; de matériel mais surtout humain. Les ISPs ne sont déjà pas capables de correctement gérer le routage de leur réseau correctement, alors je n'imagine même pas avec des plaques régionales. Si on rajoute à cela que les pris sont réellement tirés vers le bas, je ne vois vraiment pas de raisons de se plaindre. En revanche on pourrait et devrait s'interroger sur la résilience de l'internet Français dans le sens ou en effet si on coupe tout TH2 cela se passe très mal. Avoir gros points physiquement très éloignés en France pour interconnecter et héberger le contenu devrait être une recommandation étatique (Paris / Marseille par exemple). -- Raphael Mazelier On 28/04/2022 12:29, Philippe ASTIER via frnog wrote: Bah oui, ya des trucs qui ne vont pas… Idem pour moi hier, sur Free, impossible de sortir de mon premier hop, alors que si je ne me trompe pas il y a du peering sur Strasbourg. Et quand je passe de Free à OVH, il y a au moins 12 hops, ça passe par Paris, et j’ai une latence de 15 ms pour faire… 2 km physiques. C’est absurde, ca laisse songeur. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Nombreuses coupures de fibres optiques en France
On 28/04/2022 14:45, Pierre DOLIDON wrote: faudrait faire une doublette TH2 et le NetCenter SFR à CBV et là t'es tranquille TH2 ça serait compliqué je pense. Netcenter je pense qu'à force il n'est plus si important sauf pour SFR. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [TECH] Le "nom" des serveurs autoritaires de la zone .arpa change à partir du 25 avril.
On 16/04/2022 19:09, Stephane Bortzmeyer wrote: Un adjudant est autoritaire, un serveur DNS fait autorité. J'ai voulu corriger et je me suis dit qu'il n'y a qu'une seule personne faisant autorité sur le sujet en France :) -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Les routeurs dépendent-ils du serveur de licence ?
Sur ce que je connais le mieux : junos sur du mx gamme classique (240, 480, 960 qui constituent encore le cœur de nombreux réseaux opérateur) il n'y a ma connaissance aucun mécanisme de licence enforcé. Si c'était le cas cela voudrait dire que tout les routeurs en circulation devraient avoir des licences à jour et être dûment déclaré chez Juniper. Hors de ce que j'en sais (ou même déployé) il existe de nombreux routeur en prod issu du grey market avec un junos hors support. A priori tout ces routeurs sont toujours up and running. -- Raphaël Mazelier On 13/03/2022 16:08, David Ponzone wrote: Perso, j’y crois pas. Il y a forcément des réseaux sur lesquels les routeurs n’ont pas accès au net, pour des raisons de topo ou de sécurité. Quelqu’un veut bien faire le test ? David Ponzone Le 13 mars 2022 à 15:48, Wallace a écrit : Pas entendu parlé mais ça m'étonnerait à peine et beaucoup de réseaux sont full open en sortie même si l'entrée est filtrée, je doute même que beaucoup de monde aient une vue sur le trafic émis par un backbone puisqu'il n'y a pas de firewall pour loguer et filtrer en amont. En tout cas je sors les popcorns j'ai hâte de voir les retours. Le 13/03/2022 à 14:27, Stephane Bortzmeyer a écrit : Dans le cadre de la réflexion sur la robustesse de l'Internet au cas où un russe / un chat / un chat russe couperait les câbles transatlantiques, certains disent que les routeurs Cisco / Juniper / etc cesseraient de fonctionner au bout de N jours s'ils ne peuvent pas joindre leur serveur de licences. Cela me parait fort de café (bien des routeurs sont dans des réseaux fermés, sans accès à l'extérieur) mais avez-vous des informations fiables à ce sujet ? --- 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] Internet dans les médias
On 13/03/2022 16:12, David Ponzone wrote: Occasion de parler de la résilience de l’Internet FR aussi, car j’ai du mal personnellement à imaginer l’impact d’un sabotage massif de TH2. Je me suis toujours posé la question. A mon avis l'internet français grand public survivrait largement mais avec de nombreuses perturbations principalement sur le b2b. De nombreux opérateurs ont toujours la majorité de leurs liens centralisé à TH2. -- Raphaël Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Problèmes envoi de mail vers GMAIL
Hello, Reporté depuis d'autre listes, Gmail semble être en train de durcir sa politique d'acceptation de mail ; notamment en effet dans le cas d'enregistrement SPF manquant, invalide ou trop laxiste. -- Raphael Mazelier On 08/03/2022 11:55, Lionel RIVIERE wrote: Bonjour la communauté Depuis quelques jours d'énormes souci de blocages de la part de gmail, sur des adresses expéditrices, avec différents serveurs SMTP paramétrés qui fonctionnaient correctement auparavant Exemple de message de non remise : <mailto:...@gmail.com>: host gmail-smtp-in.l.google.com[173.194.76.27] said: 550-5.7.26 This message does not have authentication information or fails to 550-5.7.26 pass authentication checks. To best protect our users from spam, the 550-5.7.26 message has been blocked. Please visit 550-5.7.26 https://support.google.com/mail/answer/81126#authentication for more 550 5.7.26 information. y13-20020a05600015cd00b001f049994906si9435607wry.268 - gsmtp (in reply to end of DATA command) Quelqu'un aurait-il connaissance d'un quelquonque changement de politique de la part de gmail ou d'un autre parametre expliquant ce constat? Merci pour votre aide Lionel RIVIERE --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Géolocalisation IP France TV
Je peux répondre à ça. Tout contenu non possédé/produit par la chaîne elle même est lié à des ayants droits par contrat. Le broadcaster achète un droit pour diffuser un événement/série/film whatever pour une zone géographique, et une durée donnée. En conséquence le broadcaster est forcé d'utiliser toutes les mesures techniques nécessaires pour faire respecter ses contrats ce qui implique donc un filtrage géographique par utilisation de base geoip. C'est imparfait mais cela satisfait les ayants droits. Par ailleurs dans mon ex-job on utilisait un système d'activation/désactivation de cette restriction géo en fonction des contenu (pour le live). Et certain live tel que les chaînes d'informations n'étaient pas filtrés. -- Raphaël Mazelier On 17/02/2022 10:58, Wallace wrote: Je rebondi sur cela, quid des français expatriés? Pourquoi limiter géographiquement les IPs? Ceux qui veulent absolument voir les flux prendrons des VPN mais le grand public ne le fera pas, donc les gens normaux sont pénalisés quand les "pirates" ne sont pas inquiétés. Ce n'est pas une critique mais j'aimerais comprendre la logique derrière ce filtrage. Le 16/02/2022 à 19:51, ic a écrit : Bon finalement je réponds publiquement parce que ça peut concerner plus de monde. Le bon service chez France TV c’est le mien, le moyen le plus simple de le joindre c’estpeer...@francetv.fr, on est sympa et réactifs. Pour info la plupart des sites/services passent par Akamai et c’est leur base qui est utilisée. A ma connaissance c’est la leur, elle n’est partagée avec personne d’autre. Parfois on obtient gain de cause, parfois non. ++ ic --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Géolocalisation IP France TV
La plupart du monde utilise maxmind mais je ne sais pas pour FTV. Je commencerais en tout cas mes recherches par la. On 16/02/2022 18:14, Toussaint OTTAVI wrote: Le 16/02/2022 à 17:45, x.r...@sipleo.com a écrit : On a une IP bien française qui ressort sur Pays-Bas avec France.tv Méthode certes un peu empirique mais que j'ai utilisée dans un cas similaire : - chercher "IP geolocation" dans un moteur de recherche - faire un test chez les différents prestataires et tenter de trouver celui ou ceux qui fournissent des informations incorrectes - contacter lesdits prestataires et leur demander de mettre à jour leurs bases --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Développement Asterisk
A l'époque Axialys (ping Nicolas Bougues) faisait ça. Je ne sais plus si c'est toujours le cas. -- Raphael On 14/02/2022 09:04, Mickael Monsieur wrote: Hello, On est spécialisé dans le dev agi-bin pour des automates d’émission tv en Belgique (RTL). Tu peux me contacter privé. Mickael Le 14 févr. 2022 à 07:46, Bertrand DEBOISVILLIERS a écrit : Bonjour, Je cherche une entreprise capable de faire du développement sur Astrerisk (plan d’appel…etc). Auriez-vous un contact à me fournir (de préférence Français) ? Merci. Bertrand. --- 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] Test de connectivité
C'est Scully qui va être contente. On pourra enfin appeler internet. On 10/02/2022 14:50, Stephane Bortzmeyer wrote: Lu sur la liste NANOG, une proposition de réserver le nom de domaine "internet", et qu'il ait des enregistrements et A qui répondent à ICMP echo, de manière à ce qu'on puisse taper : ping internet pour vérifier sa connectivité. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] ONT vs ONT SFP ?
=> ORANGE, l'ONT est intégré à la BOX, y compris avec l'offre just fibre. A part avoir un ONT en rab et le faire enregistrer par le tech qui vient vous faire l'installation, je n'ai pas trouvé d'autre astuce. En plus l'IP est dynamique sauf à payer genre 10 ou 15EUR/mois. Je suis chez "sosh/aggrume" et cela ne pose pas de problème particulier (gate sous openbsd what else ?) J'aurais pu pousser le truc et prendre un ONT SFP mais personnellement le petit boîtier m'arrange (car il fait mediaconv au passage). Toutes les informations sont disponible sur lafibre.info (what else again ?) -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Choix d'un AS
Chacun fera selon son expérience. Avec 10k personnellement je pense que l'on peut se faire un setup Juniper des plus sympathiques sur base de chassis mx240/480. -- Raphael Mazelier On 11/12/2021 15:47, David Ponzone wrote: Avec ce budget, pour moi, y a pas photo. Un Dell en broke avec 4 x 10G et 2 slots PCI libres, c’est dans les 1300€. Avec 6Wind dessus (dans les 3000€ pour la licence 10G perpétuelle), t’es le roi du monde. Tu pourras même payer le support 6Wind tous les ans pour avoir les mises à jour (ça n’arrête pas), alors qu’avec un Cisco en broke, c’est compliqué de prendre un Smartnet je crois, sauf après d’un broker agréé Cisco qui sera plus cher. Attention sur 6Wind (à cause de DPDK je crois), surtout pas de multi-CPU! Donc un seul CPU, avec le max de core, sachant qu’en gros c’est 10Gbps par core. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Résolveurs DNS
On 25/11/2021 11:04, Mickael MONSIEUR wrote: Bonjour, Qu'est-ce que vous conseillez comme résolveur DNS pour ISP? Hello, Un mix de unbound et knot surement. Cdt, -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] RFC 9107: BGP Optimal Route Reflection (BGP ORR)
On 14/09/2021 16:56, Pierre Emeriaud wrote: ORR on utilise depuis que nos rr ipv4 sont passés off-path, mais uniquement pour les routeurs qui ne supportent pas add-path, parce que add-path est tout de même mieux, plus déterministe. Il ne dépend pas de l'igp, tu fais ce que tu veux avec les LP. Ah intérressant. En effet dans ce cas ORR est utile sinon j'avais toujours considéré qu'avec add-path c'était un peu une feature inutile. Bon peut etre qu'il faudrait virer les routeurs qui ne supportent pas add-path parce que c'est pas tout jeune non plus mais sur un gros backbone j'entends que ce ne soit pas forcément facile. Dans le cas d'orr chacun de nos rr calcule la best vis-à-vis de deux routeurs de référence (les gateways/asbr) jusqu'au next-hop, par région/peer-group, et annonce ladite best aux clients. Avec add-path pas besoin de la calculer, on joue juste sur les localpref sur les RR, et bonus ça permet même de définir précisément des backups de région, au cas où les deux asbr d'une région viendrait à ne plus fonctionner en même temps. Chaque RR annonce donc l'intégralité des prises de sortie à tous les PE, et les lp (puis métriques igp) jouent leur rôle. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [ML] [FRnOG] [ALERT] Moji down?
On 03/09/2021 17:17, Thomas Quinot wrote: Le fin mot de l'histoire sur leur nouvelle page d'état de santé : https://status.moji.fr/ En effet ça a coupé de 10:47 à 11:25. Un post mortem technique et honnete c'est plaisant. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Geolocalisation IP sur les plateformes de streaming
On 25/08/2021 09:10, Vincent Bernat wrote: Il y a plein de bases différentes et les content providers sont plutôt discrets pour te dire quelle base ils utilisent. Il y a quelques indices sur comment faire corriger la base de chaque provider ici (plutôt orienté US) : https://thebrotherswisp.com/index.php/geo-and-vpn/ Pour FranceTV, je n'ai jamais trouvé un contact. Pour Netflix, c'est normalement rapide si tu as effectivement des utilisateurs dans ce range. Cela vaut le coup de faire chacun des providers de la liste préventivement et de proposer systématiquement un geofeed pour éviter d'avoir à refaire la démarche régulièrement. Je ne peux parler que pour ce que je connaissais dans une ex-vie ; nous utilisions un mix de solution basée sur 1) la geoloc du CDN 2) du maxmind geoip2. Au final pour un grand évenement nous avions crée un micro-service de géoloc maison basé sur différente sources (maxmind + autres) notamment pour détecter les VPNs et avoir une single source of truth. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] [BGP] question de trolldi à équilibrer deux transits pour un /24 (en angliche : load-balancer)
On 25/06/2021 19:21, Alarig Le Lay wrote: Ils peerent avec les T1, donc ils sont T1 : https://bgp.he.net/AS7922#_graph4 Et $big_french_fai est T1 aussi : https://bgp.he.net/AS5511#_graph4 La définition d'un tiers 1 ca reste pour moi un AS qui apprend tout internet via des peerings gratuits. A minima donc avec l'ensemble des autres Tiers1. Le problème c'est qu'on ne sait pas vraiment qui paye qui. Ou du moins on a de forte suspiscion dans certains cas. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Observium & F5, soucis de charge DB
Puisqu'on est vendredi ; es tu vraiment sur de mettre en place un systeme de monitoring basé sur rrd en 2021 ? Observium étant ce qu'il est j'espere que tu as des équipements réseaux qui supportent le snmp aggressif et en effet une infrastructure systeme conséquente. Btw tes F5 tu les polls ou tu les mets en load balancer ? vu l'erreur j'aurais tendance à dire que tu les polls, mais c'est intérressant car tu viens sans doute de découvrir soit un bug d'observium soit un bug sur tes F5 ou tu as trop de truc qui bouge. -- Raph On 25/06/2021 11:22, Cécile Martron via frnog wrote: Hello à tous ! On est actuellement en train de mettre en place à Engie un Observium pour monitorer nos +1k devices réseaux. L'archi est avec un RRDcache (master) + 4/5 pollers et une DB (AWS) Le soucis, c'est qu'en rajoutant nos F5 (qui sont, certes, un peu chargés), on fait x11 sur le nombre de connection en DB. Et le load explose. La commande SQL liée : "UPDATE lb_pool_members" Avez vous déja eu ce soucis ? Savez vous le résoudre ? Merci beaucoup :) Cécile --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
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/
