RE: [FRnOG] [TECH] mikrotik lora8_kit
Hello, ça fonctionne jusqu'à quelques objets effectivement mais une fois qu'on multiplies les modules, objenious vient taper à la porte pour te dire qu'il est temps d'arrêter de jouer :) Mais pour un poc sur quelques modules, après avoir créé les codecs il y a moyen de jouer un peu ! Joffrey -Original Message- From: Paul Caranton Sent: mardi 3 mars 2020 22:37 To: Joffrey Fontaine Cc: Marc Abel ; frnog@frnog.org Subject: Re: [FRnOG] [TECH] mikrotik lora8_kit Bonsoir, Chez Objenious, il est possible d’utiliser le réseau LoRaWAN sans avoir un « objet » certifié. En tout cas, c’était possible au S1 2019 avec l’offre Objenious Starter, puisque je l’ai fait pour 2 STM32 avec chacun leur module LoRaWAN (I-NUCLEO-LRWAN1). J’ai inscrit les DevEUI de mes modules sur le site et j’ai paramétré les AppEUI et Appkey, et zou. Ce qui a été un peu plus difficile c’est d’obtenir la documentation pour « coder » son propre « driver », qui permet de transformer la trame LoRaWan en un JSON. Ce « codage » est lui-même un JSON dont le format a été défini par Objenious. Si certains cherchent cette documentation, je dois pouvoir la retrouver. Par contre, c’est vrai qu’un SIRET est demandé. Mais je ne sais pas s’il est réellement vérifié, puisque les factures étaient à mon nom, alors que je m’étais inscrit avec le SIRET de ma boite et mon adresse mail pro (les « objets » étaient un projet pro). Paul > Le 3 mars 2020 à 20:53, Joffrey Fontaine a écrit : > > /!\ sur un opérateur public, tu ne peux pas prendre ton ESP32 ou ton STM32 de > base avec un module lorawan et l'inscrire sur leur réseau, il faut qu'ils > l'aient "validé" avant (5K€). > > -Original Message- > From: frnog-requ...@frnog.org On Behalf Of > Marc Abel > Sent: lundi 2 mars 2020 19:07 > To: frnog@frnog.org > Subject: Re: [FRnOG] [TECH] mikrotik lora8_kit > > Merci Rémy, > > Je m'intéresse plutôt à LoRaWan, mais il faut connaitre aussi la techno > sous-jascente. > > Si je comprends bien divers opérateurs disposent de réseaux de passerelles et > de serveurs, ils proposent des services payants mais : > > - quelle est leur couverture effective en métropole ? > > - les devices des uns et des autres se trouvent en concurrence (côté > radio) cela peut-il poser (tôt ou tard) des soucis et réduire la portée > opérationnelle des passerelles ? > > - certains ici sont-ils dans une activité commerciale de ce type (j'ai rien > contre, c'est pour savoir) ? > > - TheThingsNetwork fait-il de l'ombre aux opérateurs ou bien sont-ils sur des > usages bien différents ? > > Bien cordialement, > > Marc Abel > >> Le 02/03/2020 à 13:20, Rémy Grünblatt a écrit : >> Salut, >> >> Tout d'abord, il faut différencier LoRa (le protocole de transmission >> physique, comme on peut dire FSK, ou QAM par exemple) de LoRaWan, qui >> est l'utilisation de LoRa pour établir un WAN (Wide-area network). >> LoRaWan permet, pour simplifier, d'utiliser LoRa pour envoyer des >> messages vers des gateway qui sont connectées à Internet et qui >> relaie ces messages sur le réseau, vers un silo (par exemple) en >> utilisant MQTT (par exemple). >> >> Rien n'empêche d'utiliser LoRa pour faire communiquer deux choses >> directement, sans plus d'infrastructure que ça, à condition d'être à >> portée bien evidemment. >> >> >> Ensuite, sur la question du nombre de messages par jour. Par défaut >> (classe A), LoRa est prévu pour fonctionner comme le protocole Aloha: >> quand on a envie d'envoyer un message, on l'envoie directement, sans >> vérifier si le canal est utilisé, et il n'y a pas d'acquittement >> (mais on peut en demander). Ça permet d'éviter de perdre de l'énergie >> à écouter le canal, et de se mettre en deep sleep si on a rien à >> envoyer, mais, possibilité de collision, de perte des données. Pour >> éviter trop de collision, la loi prévoie que sur la bande des 868MHz, >> il n'est possible d'émettre que 1% du temps. Par exemple, si j'émets >> pendant une seconde, je dois me taire pendant 99 secondes. Mais si >> j'émets pendant 1 centième de seconde, je peux donc envoyer un >> message par seconde. Pour savoir combien de données je peux envoyer, >> il est nécessaire de regarder quelles sont les modulations à >> disposition (mais, LoRa n'est pas fait pour envoyer beaucoup de données, >> c'est fait pour de l'IOT à la base). >> Les classes B et C compliquent un peu l'envoi, mais ça reste la même idée. >> >> Il est possible de demander à son noeud qui parle LoRa d'écouter le >> canal avant de parler, pour éviter de brouiller des transmissions >> concurrentes, et là, alors, il est possible d'utiliser ce mode de >> transmission autant de temps que l'on veut, pour peu que l'on ne soit >> pas en train de brouiller quelqu'un (i.e. on émet pas quand on >> détecte quelqu'un parler, comme pour le WiFi version < 6), d'après la >> législation. >> >> Petite application numérique: >> >> - En utilisant la modulation la plus robuste (SF 1
Re: [FRnOG] [TECH] mikrotik lora8_kit
Bonsoir, Chez Objenious, il est possible d’utiliser le réseau LoRaWAN sans avoir un « objet » certifié. En tout cas, c’était possible au S1 2019 avec l’offre Objenious Starter, puisque je l’ai fait pour 2 STM32 avec chacun leur module LoRaWAN (I-NUCLEO-LRWAN1). J’ai inscrit les DevEUI de mes modules sur le site et j’ai paramétré les AppEUI et Appkey, et zou. Ce qui a été un peu plus difficile c’est d’obtenir la documentation pour « coder » son propre « driver », qui permet de transformer la trame LoRaWan en un JSON. Ce « codage » est lui-même un JSON dont le format a été défini par Objenious. Si certains cherchent cette documentation, je dois pouvoir la retrouver. Par contre, c’est vrai qu’un SIRET est demandé. Mais je ne sais pas s’il est réellement vérifié, puisque les factures étaient à mon nom, alors que je m’étais inscrit avec le SIRET de ma boite et mon adresse mail pro (les « objets » étaient un projet pro). Paul > Le 3 mars 2020 à 20:53, Joffrey Fontaine a écrit : > > /!\ sur un opérateur public, tu ne peux pas prendre ton ESP32 ou ton STM32 de > base avec un module lorawan et l'inscrire sur leur réseau, il faut qu'ils > l'aient "validé" avant (5K€). > > -Original Message- > From: frnog-requ...@frnog.org On Behalf Of Marc Abel > Sent: lundi 2 mars 2020 19:07 > To: frnog@frnog.org > Subject: Re: [FRnOG] [TECH] mikrotik lora8_kit > > Merci Rémy, > > Je m'intéresse plutôt à LoRaWan, mais il faut connaitre aussi la techno > sous-jascente. > > Si je comprends bien divers opérateurs disposent de réseaux de passerelles et > de serveurs, ils proposent des services payants mais : > > - quelle est leur couverture effective en métropole ? > > - les devices des uns et des autres se trouvent en concurrence (côté > radio) cela peut-il poser (tôt ou tard) des soucis et réduire la portée > opérationnelle des passerelles ? > > - certains ici sont-ils dans une activité commerciale de ce type (j'ai rien > contre, c'est pour savoir) ? > > - TheThingsNetwork fait-il de l'ombre aux opérateurs ou bien sont-ils sur des > usages bien différents ? > > Bien cordialement, > > Marc Abel > >> Le 02/03/2020 à 13:20, Rémy Grünblatt a écrit : >> Salut, >> >> Tout d'abord, il faut différencier LoRa (le protocole de transmission >> physique, comme on peut dire FSK, ou QAM par exemple) de LoRaWan, qui >> est l'utilisation de LoRa pour établir un WAN (Wide-area network). >> LoRaWan permet, pour simplifier, d'utiliser LoRa pour envoyer des >> messages vers des gateway qui sont connectées à Internet et qui relaie >> ces messages sur le réseau, vers un silo (par exemple) en utilisant >> MQTT (par exemple). >> >> Rien n'empêche d'utiliser LoRa pour faire communiquer deux choses >> directement, sans plus d'infrastructure que ça, à condition d'être à >> portée bien evidemment. >> >> >> Ensuite, sur la question du nombre de messages par jour. Par défaut >> (classe A), LoRa est prévu pour fonctionner comme le protocole Aloha: >> quand on a envie d'envoyer un message, on l'envoie directement, sans >> vérifier si le canal est utilisé, et il n'y a pas d'acquittement (mais >> on peut en demander). Ça permet d'éviter de perdre de l'énergie à >> écouter le canal, et de se mettre en deep sleep si on a rien à >> envoyer, mais, possibilité de collision, de perte des données. Pour >> éviter trop de collision, la loi prévoie que sur la bande des 868MHz, >> il n'est possible d'émettre que 1% du temps. Par exemple, si j'émets >> pendant une seconde, je dois me taire pendant 99 secondes. Mais si >> j'émets pendant 1 centième de seconde, je peux donc envoyer un message >> par seconde. Pour savoir combien de données je peux envoyer, il est >> nécessaire de regarder quelles sont les modulations à disposition >> (mais, LoRa n'est pas fait pour envoyer beaucoup de données, c'est fait pour >> de l'IOT à la base). >> Les classes B et C compliquent un peu l'envoi, mais ça reste la même idée. >> >> Il est possible de demander à son noeud qui parle LoRa d'écouter le >> canal avant de parler, pour éviter de brouiller des transmissions >> concurrentes, et là, alors, il est possible d'utiliser ce mode de >> transmission autant de temps que l'on veut, pour peu que l'on ne soit >> pas en train de brouiller quelqu'un (i.e. on émet pas quand on détecte >> quelqu'un parler, comme pour le WiFi version < 6), d'après la législation. >> >> Petite application numérique: >> >> - En utilisant la modulation la plus robuste (SF 12), on peut envoyer >> 50 octets en un peu plus de 2 secondes, c'est-à-dire qu'on peut >> envoyer environ 18 messages par heure sur une fréquence >> - En utilisant la modulation la plus rapide (moins robuste) (SF 7), on >> peut envoyer 50 octets en environ 100 millisecondes, soit 360 messages >> par heure sur une fréquence >> >> >> C'est un gros résumé, y'a plein de raccourcis, mais c'est comme ça que >> ça se passe, en gros. >> >> Rémy >> >> >>> On 02/03/2020 11:36, Oliv
Re: [FRnOG] [TECH] mikrotik lora8_kit
Bonsoir Ce genre de technos (lora et sigfox) sont super intéressantes mais lorsque vous désirez vous lancer dans un désign comme amateur c'est chasse gardé. Je me suis commandé en sigfox un tracker wifi à 25euros et bien chez sigfox vous devez passer par l'abo à 10 devices à 60euros pour activer le service. Il y a le kit étudiant mais je pense qu' il doit coûter un bras Idem en lorawan chez nos deux opérateurs mobile GSM. Si vous n'avez pas de SIREN c est passe ton chemin. Heureusement pour le DIY il y a yadom en France Pour info une SIM à 10 euros et un module 2G simcom à moins de 5euros et la techno est vraiment accessible à tous . Ttgo a lancé fin decembre un module esp32 avec un sim7000G et son antenne gps a moins de 40euros . Par contre le gsm/LTE-M à beaucoup d'inconvénients face à la bande des 868Mhz. Le jour ou sur du lora et sigfox il sera aussi simple de se fournir je pense que le marché sera prêt à exploser... Richard Le mar. 3 mars 2020 à 20:53, Joffrey Fontaine a écrit : > Hello, à $Job on utilise énormément LoRaWAN, > > On déploie notre réseau privé avec des gateway multitech ( > https://www.multitech.com/brands/multiconnect-conduit) qui ont le truc > cool d'exister en version 4G avec VPN. Du coup pour déployer dans la pampa > c'est très intéressant. > Si on veut faire du réseau opéré, on utilise un peu celui d'orange, mais > beaucoup celui de bouygue (Objenious) qui possède une carte +- correcte de > couverture (https://spot.objenious.com/eligibility-public) > > /!\ sur un opérateur public, tu ne peux pas prendre ton ESP32 ou ton STM32 > de base avec un module lorawan et l'inscrire sur leur réseau, il faut > qu'ils l'aient "validé" avant (5K€). > Pour ceux qui veulent juste du relais déporté, il existe quelques modules > bien pratique, et français :) > https://www.adeunis.com/en/produit/dry-contacts-0-1-status/ par exemple, > sans aucune action. On a plusieurs fournisseurs :) > > Joffrey > > -Original Message- > From: frnog-requ...@frnog.org On Behalf Of Marc > Abel > Sent: lundi 2 mars 2020 19:07 > To: frnog@frnog.org > Subject: Re: [FRnOG] [TECH] mikrotik lora8_kit > > Merci Rémy, > > Je m'intéresse plutôt à LoRaWan, mais il faut connaitre aussi la techno > sous-jascente. > > Si je comprends bien divers opérateurs disposent de réseaux de passerelles > et de serveurs, ils proposent des services payants mais : > > - quelle est leur couverture effective en métropole ? > > - les devices des uns et des autres se trouvent en concurrence (côté > radio) cela peut-il poser (tôt ou tard) des soucis et réduire la portée > opérationnelle des passerelles ? > > - certains ici sont-ils dans une activité commerciale de ce type (j'ai > rien contre, c'est pour savoir) ? > > - TheThingsNetwork fait-il de l'ombre aux opérateurs ou bien sont-ils sur > des usages bien différents ? > > Bien cordialement, > > Marc Abel > > Le 02/03/2020 à 13:20, Rémy Grünblatt a écrit : > > Salut, > > > > Tout d'abord, il faut différencier LoRa (le protocole de transmission > > physique, comme on peut dire FSK, ou QAM par exemple) de LoRaWan, qui > > est l'utilisation de LoRa pour établir un WAN (Wide-area network). > > LoRaWan permet, pour simplifier, d'utiliser LoRa pour envoyer des > > messages vers des gateway qui sont connectées à Internet et qui relaie > > ces messages sur le réseau, vers un silo (par exemple) en utilisant > > MQTT (par exemple). > > > > Rien n'empêche d'utiliser LoRa pour faire communiquer deux choses > > directement, sans plus d'infrastructure que ça, à condition d'être à > > portée bien evidemment. > > > > > > Ensuite, sur la question du nombre de messages par jour. Par défaut > > (classe A), LoRa est prévu pour fonctionner comme le protocole Aloha: > > quand on a envie d'envoyer un message, on l'envoie directement, sans > > vérifier si le canal est utilisé, et il n'y a pas d'acquittement (mais > > on peut en demander). Ça permet d'éviter de perdre de l'énergie à > > écouter le canal, et de se mettre en deep sleep si on a rien à > > envoyer, mais, possibilité de collision, de perte des données. Pour > > éviter trop de collision, la loi prévoie que sur la bande des 868MHz, > > il n'est possible d'émettre que 1% du temps. Par exemple, si j'émets > > pendant une seconde, je dois me taire pendant 99 secondes. Mais si > > j'émets pendant 1 centième de seconde, je peux donc envoyer un message > > par seconde. Pour savoir combien de données je peux envoyer, il est > > nécessaire de regarder quelles sont les modulations à disposition > > (mais, LoRa n'est pas fait pour envoyer beaucoup de données, c'est fait > pour de l'IOT à la base). > > Les classes B et C compliquent un peu l'envoi, mais ça reste la même > idée. > > > > Il est possible de demander à son noeud qui parle LoRa d'écouter le > > canal avant de parler, pour éviter de brouiller des transmissions > > concurrentes, et là, alors, il est possible d'utiliser ce mode de > > transmission autant de temps que l'on veut, pour peu que l'on n
RE: [FRnOG] [TECH] mikrotik lora8_kit
Hello, à $Job on utilise énormément LoRaWAN, On déploie notre réseau privé avec des gateway multitech (https://www.multitech.com/brands/multiconnect-conduit) qui ont le truc cool d'exister en version 4G avec VPN. Du coup pour déployer dans la pampa c'est très intéressant. Si on veut faire du réseau opéré, on utilise un peu celui d'orange, mais beaucoup celui de bouygue (Objenious) qui possède une carte +- correcte de couverture (https://spot.objenious.com/eligibility-public) /!\ sur un opérateur public, tu ne peux pas prendre ton ESP32 ou ton STM32 de base avec un module lorawan et l'inscrire sur leur réseau, il faut qu'ils l'aient "validé" avant (5K€). Pour ceux qui veulent juste du relais déporté, il existe quelques modules bien pratique, et français :) https://www.adeunis.com/en/produit/dry-contacts-0-1-status/ par exemple, sans aucune action. On a plusieurs fournisseurs :) Joffrey -Original Message- From: frnog-requ...@frnog.org On Behalf Of Marc Abel Sent: lundi 2 mars 2020 19:07 To: frnog@frnog.org Subject: Re: [FRnOG] [TECH] mikrotik lora8_kit Merci Rémy, Je m'intéresse plutôt à LoRaWan, mais il faut connaitre aussi la techno sous-jascente. Si je comprends bien divers opérateurs disposent de réseaux de passerelles et de serveurs, ils proposent des services payants mais : - quelle est leur couverture effective en métropole ? - les devices des uns et des autres se trouvent en concurrence (côté radio) cela peut-il poser (tôt ou tard) des soucis et réduire la portée opérationnelle des passerelles ? - certains ici sont-ils dans une activité commerciale de ce type (j'ai rien contre, c'est pour savoir) ? - TheThingsNetwork fait-il de l'ombre aux opérateurs ou bien sont-ils sur des usages bien différents ? Bien cordialement, Marc Abel Le 02/03/2020 à 13:20, Rémy Grünblatt a écrit : > Salut, > > Tout d'abord, il faut différencier LoRa (le protocole de transmission > physique, comme on peut dire FSK, ou QAM par exemple) de LoRaWan, qui > est l'utilisation de LoRa pour établir un WAN (Wide-area network). > LoRaWan permet, pour simplifier, d'utiliser LoRa pour envoyer des > messages vers des gateway qui sont connectées à Internet et qui relaie > ces messages sur le réseau, vers un silo (par exemple) en utilisant > MQTT (par exemple). > > Rien n'empêche d'utiliser LoRa pour faire communiquer deux choses > directement, sans plus d'infrastructure que ça, à condition d'être à > portée bien evidemment. > > > Ensuite, sur la question du nombre de messages par jour. Par défaut > (classe A), LoRa est prévu pour fonctionner comme le protocole Aloha: > quand on a envie d'envoyer un message, on l'envoie directement, sans > vérifier si le canal est utilisé, et il n'y a pas d'acquittement (mais > on peut en demander). Ça permet d'éviter de perdre de l'énergie à > écouter le canal, et de se mettre en deep sleep si on a rien à > envoyer, mais, possibilité de collision, de perte des données. Pour > éviter trop de collision, la loi prévoie que sur la bande des 868MHz, > il n'est possible d'émettre que 1% du temps. Par exemple, si j'émets > pendant une seconde, je dois me taire pendant 99 secondes. Mais si > j'émets pendant 1 centième de seconde, je peux donc envoyer un message > par seconde. Pour savoir combien de données je peux envoyer, il est > nécessaire de regarder quelles sont les modulations à disposition > (mais, LoRa n'est pas fait pour envoyer beaucoup de données, c'est fait pour > de l'IOT à la base). > Les classes B et C compliquent un peu l'envoi, mais ça reste la même idée. > > Il est possible de demander à son noeud qui parle LoRa d'écouter le > canal avant de parler, pour éviter de brouiller des transmissions > concurrentes, et là, alors, il est possible d'utiliser ce mode de > transmission autant de temps que l'on veut, pour peu que l'on ne soit > pas en train de brouiller quelqu'un (i.e. on émet pas quand on détecte > quelqu'un parler, comme pour le WiFi version < 6), d'après la législation. > > Petite application numérique: > > - En utilisant la modulation la plus robuste (SF 12), on peut envoyer > 50 octets en un peu plus de 2 secondes, c'est-à-dire qu'on peut > envoyer environ 18 messages par heure sur une fréquence > - En utilisant la modulation la plus rapide (moins robuste) (SF 7), on > peut envoyer 50 octets en environ 100 millisecondes, soit 360 messages > par heure sur une fréquence > > > C'est un gros résumé, y'a plein de raccourcis, mais c'est comme ça que > ça se passe, en gros. > > Rémy > > > On 02/03/2020 11:36, Oliver varenne wrote: >> Je suis completement nul dans ce domaine Mais LORA ça permet de faire >> transiter que quelques messages par jour non ? de quelques dizaine de B maxi >> non ? >> Donc à mon sens pas possible de faire fonctionner une CLI... ou alors je me >> trompe ? >> >> >> >> Cordialement, >> >> >> >> Olivier Varenne >> Co-gérant, Commercial & Développeur >> T +33 (0)4 27 04 40 00 | ipconnect.fr >> >> Suive
Re: [FRnOG] [MISC] FRnOG 34.0 - RC2
Bonsoir, Un petit point Corona (pas la bière), pour les inquiets... Pour l'instant, la réunion n'est pas interdite car elle est sous la barrière des 5000 personnes. Par contre, nous allons observer quelques règles de bases de bienséance en période d'épidémie : - pas de contacts entre humains (bises, serrages de mains, etc.) - les serveurs seront les seuls habilités à servir les boissons lors des différentes pauses (pas de self service) - sauf pénurie, on essaiera de mettre à disposition des SHA (solution hydro alcooliques) Comme d'habitude, on peut compter sur l'équipe de l'Hôtel (5 étoiles) pour que l'hygiène du lieu soit impeccable. Si la situation venait à évoluer au niveau de ce qui est autorisé ou pas par le ministère de la santé concernant la liberté de se réunir, vous en serriez rapidement informés... IMHO, il n'y a pas de stress particulier à avoir, ce virus n'est pas mortel dans la tranche d'âge de la majorité des membres du FRnOG et il est quand même 5 fois moins contagieux que la gastro (R0 de 2-3 vs 14-15). Bref, no stress ! Cordialement, -- Philippe Bourcier web : http://sysctl.org/ blog : https://www.linkedin.com/today/author/philippebourcier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Double connexion internet
Merci à tous le monde pour les retours je vais étudier les différents solution et voir si cela réponds à mon besoin aussi Hervé On Tue, Mar 3, 2020 at 10:53 AM GUILLAUME Cyrille < cyrille.guilla...@vicat.fr> wrote: > Le 40F est largement suffisant au vu des perfs annoncées > > > Cyrille GUILLAUME > Network & Security Engineer > +33 (0)4 37 06 24 34 > > DSI > TSA 39604 > 38080 - L'ISLE D'ABEAU CEDEX > www.vicat.fr > > > -Message d'origine- > De : frnog-requ...@frnog.org De la part de > Guillaume Tournat via frnog > Envoyé : lundi 2 mars 2020 23:57 > À : Dang Herve > Cc : frnog-t...@frnog.org > Objet : Re: [FRnOG] [TECH] Double connexion internet > > Firewall FortiGate (de Fortinet). > Le Sdwan est natif. Un petit modèle 40F ou 60F fera très bien l’affaire. > > > > Le 1 mars 2020 à 22:13, Dang Herve a écrit : > > > > Bonjour > > > > Ayant de plus en plus soucis de connexion internet je regarde pour > > avoir une deuxième connexion chez moi je suis actuellement sur du vdsl > > mais j'ai la possibilité de pouvoir prendre une seconde sur du fttla. > > > > Pour agréger mes deux connexion je cherche donc du matériel double Wan > > je ne ne connais que l'OTB d'ovh pour du matériel "bon" marché. > > > > En aurez vous d'autre à conseiller ? > > > > Herve > > > > PS: le reseau n'est pas m'a specialité mais j'estime quand meme avoir > > de bonne notion dedans. > > > > --- > > 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] Is the Internet Resilient Enough to Withstand Coronavirus?
> Laurent Fabre a écrit : > La nocivité de la 4G, c’est les ondes qui vous frient les glandes à petit > feux ! Pour éviter cela, il faut > réduire le DAS (Dégât Au Sexe) Pour ça, une solution : le Lora ! (Long > Orgasme Régulièrement Administré) Self-administré çà marche aussi ? ;-) Sinon, il y a le slip anti-ondes : https://www.challenges.fr/high-tech/les-inventeurs-culottes-du-slip-anti-ondes-spartan-levent-un-demi-million_484758 > Olivier Calzi a écrit : > Dredi c'est tout les jours face à la bêtise. Bêtise d'autant plus grave que çà vient de l'Isoc. Si encore c'était 01net ou tous ces truc qui publient n'importe quoi pour faire vendre de la pub on comprendrait, mais là ? Le mec il devrait publier dans "National Enquirer". Ou alors faut qu'il arrête de fumer des tarpés avec Paco Rabane. Michel. >>> Stephane Bortzmeyer a écrit : >>> Vérifiez vos infras, et surtout votre peering avec Netflix : >>> https://www.internetsociety.org/blog/2020/02/is-the-internet-resilient-enough-to-withstand-coronavirus/ --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] Double connexion internet
Le 40F est largement suffisant au vu des perfs annoncées Cyrille GUILLAUME Network & Security Engineer +33 (0)4 37 06 24 34 DSI TSA 39604 38080 - L'ISLE D'ABEAU CEDEX www.vicat.fr -Message d'origine- De : frnog-requ...@frnog.org De la part de Guillaume Tournat via frnog Envoyé : lundi 2 mars 2020 23:57 À : Dang Herve Cc : frnog-t...@frnog.org Objet : Re: [FRnOG] [TECH] Double connexion internet Firewall FortiGate (de Fortinet). Le Sdwan est natif. Un petit modèle 40F ou 60F fera très bien l’affaire. > Le 1 mars 2020 à 22:13, Dang Herve a écrit : > > Bonjour > > Ayant de plus en plus soucis de connexion internet je regarde pour > avoir une deuxième connexion chez moi je suis actuellement sur du vdsl > mais j'ai la possibilité de pouvoir prendre une seconde sur du fttla. > > Pour agréger mes deux connexion je cherche donc du matériel double Wan > je ne ne connais que l'OTB d'ovh pour du matériel "bon" marché. > > En aurez vous d'autre à conseiller ? > > Herve > > PS: le reseau n'est pas m'a specialité mais j'estime quand meme avoir > de bonne notion dedans. > > --- > 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/
[FRnOG] [TECH] modem USB 4G
Bonjour la liste, Je suis à la recherche d'une référence de dongle USB 4G qui fasse modem ; la partie routeur ne m’intéresse pas car elle sera gérée directement par un routeur plus robuste. Pas besoin donc de wifi et encore moins de batterie intégrée. J'ai déjà expérimenté la modification du firmware d'un Huawei E3372 mais ça ne fonctionne pas tout le temps et comme je prévois d'en acheter une centaine prêt à l'emploi j'aurais voulu éviter toute modification à faire sur la totalité du matériel. Auriez-vous une référence à me conseiller ? Merci --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] HAProxy multi DC
Bonjour, Dans ce cas si L2 privé entre les 2 DC, peut-etre regarder pour coupler le cluster HAproxy avec une solution Keepalived juste en utilisant les fonctionnalités : - keepalive pur pour l'aspect "état du cluster" - healthcheck Haproxy pour chaque noeud (local et éventuellement remote) - nsupdate si besoin de bascule + TTL court évidemment My 2 cents. Fred Le Brigand. Le 03/03/2020 à 13:15, Mickael Hubert a écrit : Un grand merci à tous pour vos retours ! BGP pas possible coté hébergeur, ses IP arrivent de façon indépendantes sur ses 2 DC, pas possible d'annoncer le subnet du DC A sur le DC B en cas de perte du DC A. J'ai bien un L2 entre les 2 DC, mais il ne me servirait que pour le côté privé. Et d'ailleurs ça casserait mon design L3 (car j'ai remonté un L3 au dessus du L2 fourni par l'hébergeur) En gros c'est DNS, à faire soi-même ou à déléguer, mais pas le choix d'avoir un TTL très court ... Si vous avez d'autres idées, faites vous plaisir ;) ++ Le mar. 3 mars 2020 à 13:06, Michel 'ic' Luczak a écrit : Hello, On 3 Mar 2020, at 11:15, Mickael Hubert wrote: Bonjour à tous, nous devons réaliser du HA (et si possible du loadbalancing) entre 2 instances HAProxy, ces 2 Haproxy doivent-être hébergés dans 2 DC différents. Pas possible de réaliser du VRRP car nous ne pouvons pas switcher l'IP publique de l'un à l'autre des DC. La solution la plus simple serait de réaliser du round robin DNS pour pointer sur les 2 IP publiques des 2 HAproxy. Mais avant de se lancer tête baissée dans le truc, je souhaitais savoir si vous auriez d'autre solutions à me proposer ? Je fais ça pour faire du “cdn lite” pour des clients avec du varnish sur 2 serveurs dédiés. Chacun porte aussi un gdnsd avec un healthcheck des deux serveurs. Les deux sont configurés comme NS du sous domaine “static.”. En situation normale, les deux renvoient l’IP des deux, si un des deux tombe (niveau varnish) pour une raison ou une autre, une seule IP est renvoyée. Si une des deux machines tombe complètement, un seul DNS fonctionne (c’est suffisant) et ne renvoie que l’IP de la survivante. ++ ic --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] HAProxy multi DC
Résultat gslb avec gdnsd me semble une bonne solution. Les ttls court c'est moche mais tout le monde le fait alors bon. -- Raphael Mazelier On 03/03/2020 13:15, Mickael Hubert wrote: Un grand merci à tous pour vos retours ! BGP pas possible coté hébergeur, ses IP arrivent de façon indépendantes sur ses 2 DC, pas possible d'annoncer le subnet du DC A sur le DC B en cas de perte du DC A. J'ai bien un L2 entre les 2 DC, mais il ne me servirait que pour le côté privé. Et d'ailleurs ça casserait mon design L3 (car j'ai remonté un L3 au dessus du L2 fourni par l'hébergeur) En gros c'est DNS, à faire soi-même ou à déléguer, mais pas le choix d'avoir un TTL très court ... Si vous avez d'autres idées, faites vous plaisir ;) ++ Le mar. 3 mars 2020 à 13:06, Michel 'ic' Luczak a écrit : Hello, On 3 Mar 2020, at 11:15, Mickael Hubert wrote: Bonjour à tous, nous devons réaliser du HA (et si possible du loadbalancing) entre 2 instances HAProxy, ces 2 Haproxy doivent-être hébergés dans 2 DC différents. Pas possible de réaliser du VRRP car nous ne pouvons pas switcher l'IP publique de l'un à l'autre des DC. La solution la plus simple serait de réaliser du round robin DNS pour pointer sur les 2 IP publiques des 2 HAproxy. Mais avant de se lancer tête baissée dans le truc, je souhaitais savoir si vous auriez d'autre solutions à me proposer ? Je fais ça pour faire du “cdn lite” pour des clients avec du varnish sur 2 serveurs dédiés. Chacun porte aussi un gdnsd avec un healthcheck des deux serveurs. Les deux sont configurés comme NS du sous domaine “static.”. En situation normale, les deux renvoient l’IP des deux, si un des deux tombe (niveau varnish) pour une raison ou une autre, une seule IP est renvoyée. Si une des deux machines tombe complètement, un seul DNS fonctionne (c’est suffisant) et ne renvoie que l’IP de la survivante. ++ ic --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] HAProxy multi DC
Un grand merci à tous pour vos retours ! BGP pas possible coté hébergeur, ses IP arrivent de façon indépendantes sur ses 2 DC, pas possible d'annoncer le subnet du DC A sur le DC B en cas de perte du DC A. J'ai bien un L2 entre les 2 DC, mais il ne me servirait que pour le côté privé. Et d'ailleurs ça casserait mon design L3 (car j'ai remonté un L3 au dessus du L2 fourni par l'hébergeur) En gros c'est DNS, à faire soi-même ou à déléguer, mais pas le choix d'avoir un TTL très court ... Si vous avez d'autres idées, faites vous plaisir ;) ++ Le mar. 3 mars 2020 à 13:06, Michel 'ic' Luczak a écrit : > Hello, > > > On 3 Mar 2020, at 11:15, Mickael Hubert wrote: > > > > Bonjour à tous, > > nous devons réaliser du HA (et si possible du loadbalancing) entre 2 > > instances HAProxy, ces 2 Haproxy doivent-être hébergés dans 2 DC > différents. > > Pas possible de réaliser du VRRP car nous ne pouvons pas switcher l'IP > > publique de l'un à l'autre des DC. > > > > La solution la plus simple serait de réaliser du round robin DNS pour > > pointer sur les 2 IP publiques des 2 HAproxy. Mais avant de se lancer > tête > > baissée dans le truc, je souhaitais savoir si vous auriez d'autre > solutions > > à me proposer ? > > Je fais ça pour faire du “cdn lite” pour des clients avec du varnish sur 2 > serveurs dédiés. Chacun porte aussi un gdnsd avec un healthcheck des deux > serveurs. Les deux sont configurés comme NS du sous domaine “static.”. En > situation normale, les deux renvoient l’IP des deux, si un des deux tombe > (niveau varnish) pour une raison ou une autre, une seule IP est renvoyée. > Si une des deux machines tombe complètement, un seul DNS fonctionne (c’est > suffisant) et ne renvoie que l’IP de la survivante. > > ++ ic > > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] HAProxy multi DC
Hello, > On 3 Mar 2020, at 11:15, Mickael Hubert wrote: > > Bonjour à tous, > nous devons réaliser du HA (et si possible du loadbalancing) entre 2 > instances HAProxy, ces 2 Haproxy doivent-être hébergés dans 2 DC différents. > Pas possible de réaliser du VRRP car nous ne pouvons pas switcher l'IP > publique de l'un à l'autre des DC. > > La solution la plus simple serait de réaliser du round robin DNS pour > pointer sur les 2 IP publiques des 2 HAproxy. Mais avant de se lancer tête > baissée dans le truc, je souhaitais savoir si vous auriez d'autre solutions > à me proposer ? Je fais ça pour faire du “cdn lite” pour des clients avec du varnish sur 2 serveurs dédiés. Chacun porte aussi un gdnsd avec un healthcheck des deux serveurs. Les deux sont configurés comme NS du sous domaine “static.”. En situation normale, les deux renvoient l’IP des deux, si un des deux tombe (niveau varnish) pour une raison ou une autre, une seule IP est renvoyée. Si une des deux machines tombe complètement, un seul DNS fonctionne (c’est suffisant) et ne renvoie que l’IP de la survivante. ++ ic --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] HAProxy multi DC
Coucou Mickael, Sur la partie multi-cloud/multi-isp effectivement ton choix est limité. En fonction des contraintes tu peux: - t'appuyer sur un service tier pour le DNS qui en conscience adaptera la réponse sur le ou les IP publiques de tes HAProxy - le faire toi même, avec un test sur tes IP Publique et en mettant à jour les données des NS en fonction. Après si c'est du multiDC intra-AS tu peux aussi faire des IP flottantes si ton design le permet. On Tue, Mar 3, 2020 at 11:17 AM Mickael Hubert wrote: > Bonjour à tous, > nous devons réaliser du HA (et si possible du loadbalancing) entre 2 > instances HAProxy, ces 2 Haproxy doivent-être hébergés dans 2 DC > différents. > Pas possible de réaliser du VRRP car nous ne pouvons pas switcher l'IP > publique de l'un à l'autre des DC. > > La solution la plus simple serait de réaliser du round robin DNS pour > pointer sur les 2 IP publiques des 2 HAproxy. Mais avant de se lancer tête > baissée dans le truc, je souhaitais savoir si vous auriez d'autre solutions > à me proposer ? > Car à ma connaissance, si un des HAProxy est HS, le DNS n'en saura rien et > continuera à balancer du trafic dessus (avec 50% d'échec). > > Merci d'avance pour votre aide ! > > ++ > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > -- Renaud Rakotomalala --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] HAProxy multi DC
Yep globalement deux options : GSLB (du pauvre ou pas, mais j'aime bien l'approche) ou anycast BGP. -- Raphael Mazelier On 03/03/2020 11:37, Thomas Pedoussaut wrote: Tu as la version DNSLB du pauvre, j'en ai fait depuis 2007. Ca utilise le fait que naturellement, la chaine de resolution DNS va chercher à trouver un NS up pour une zone. Soit ton site www.example.com Soit ta Machine A comme ip 1.2.3.4 Soit ta Machine B comme ip 5.6.7.8 Tu cree une sous zone lb.example.com Voici un extrait de ton fichier de zone: machineA IN A 1.2.3.4 machineB IN A 5.6.7.8 lb IN NS machineA lb IN NS machineB www IN CNAME www.lb.example.com. Et sur chacun des serveur tu fais aussi tourner un bind, chacun faisant autorité pour lb.example.com Et qui contient www 60 IN A 1.2.3.4 (sur la machineA) ou www 60 IN A 5.6.7.8 (sur la machine B) (pas de master/slave pour cette zone) Si les 2 serveurs fonctionnent, tu auras grosso modo du round robin. Si un serveur est down, immédiatement les client qui n'ont pas l'IP en cache seront tous sur l'instance encore UP. Au bout de 60 sec, les cache auront expiré et pareil tout le traffic arrivera sur la machine UP Il te reste a faire un mecanisme sur chaque serveur pour eteindre bind si ton haproxy (ou tous ses backend) est down pour ne plus servir la mauvaise IP. On 03/03/2020 11:15, Mickael Hubert wrote: Bonjour à tous, nous devons réaliser du HA (et si possible du loadbalancing) entre 2 instances HAProxy, ces 2 Haproxy doivent-être hébergés dans 2 DC différents. Pas possible de réaliser du VRRP car nous ne pouvons pas switcher l'IP publique de l'un à l'autre des DC. La solution la plus simple serait de réaliser du round robin DNS pour pointer sur les 2 IP publiques des 2 HAproxy. Mais avant de se lancer tête baissée dans le truc, je souhaitais savoir si vous auriez d'autre solutions à me proposer ? Car à ma connaissance, si un des HAProxy est HS, le DNS n'en saura rien et continuera à balancer du trafic dessus (avec 50% d'échec). Merci d'avance pour votre aide ! ++ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] HAProxy multi DC
J’ai envie de dire: s’il fait l’effort de déployer une archi pareille, pour avoir les 2 sites dépendant du même transit….. > Le 3 mars 2020 à 11:29, Jugurta Yennek a écrit : > > Bonjour Mickael, > As tu la possibilité de mettre en place deux sessions BGP entre tes > HAProxy et les routeurs de ton opérateur/hébergeur et d'annoncer la même > IP (flotante) des deux cotés qui servira à ta prod ? > Avec cette solution tu peux même monitorer ton process HAPROXY et de > shut/no shut ta session BGP selon l'état de celui-ci > > --- > Jugurta Yennek > > Le 2020-03-03 11:15, Mickael Hubert a écrit : > >> Bonjour à tous, >> nous devons réaliser du HA (et si possible du loadbalancing) entre 2 >> instances HAProxy, ces 2 Haproxy doivent-être hébergés dans 2 DC différents. >> Pas possible de réaliser du VRRP car nous ne pouvons pas switcher l'IP >> publique de l'un à l'autre des DC. >> La solution la plus simple serait de réaliser du round robin DNS pour >> pointer sur les 2 IP publiques des 2 HAproxy. Mais avant de se lancer tête >> baissée dans le truc, je souhaitais savoir si vous auriez d'autre solutions >> à me proposer ? >> Car à ma connaissance, si un des HAProxy est HS, le DNS n'en saura rien et >> continuera à balancer du trafic dessus (avec 50% d'échec). >> Merci d'avance pour votre aide ! >> ++ >> --- >> Liste de diffusion du FRnOG >> http://www.frnog.org/ > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] HAProxy multi DC
Tu as la version DNSLB du pauvre, j'en ai fait depuis 2007. Ca utilise le fait que naturellement, la chaine de resolution DNS va chercher à trouver un NS up pour une zone. Soit ton site www.example.com Soit ta Machine A comme ip 1.2.3.4 Soit ta Machine B comme ip 5.6.7.8 Tu cree une sous zone lb.example.com Voici un extrait de ton fichier de zone: machineA IN A 1.2.3.4 machineB IN A 5.6.7.8 lb IN NS machineA lb IN NS machineB www IN CNAME www.lb.example.com. Et sur chacun des serveur tu fais aussi tourner un bind, chacun faisant autorité pour lb.example.com Et qui contient www 60 IN A 1.2.3.4 (sur la machineA) ou www 60 IN A 5.6.7.8 (sur la machine B) (pas de master/slave pour cette zone) Si les 2 serveurs fonctionnent, tu auras grosso modo du round robin. Si un serveur est down, immédiatement les client qui n'ont pas l'IP en cache seront tous sur l'instance encore UP. Au bout de 60 sec, les cache auront expiré et pareil tout le traffic arrivera sur la machine UP Il te reste a faire un mecanisme sur chaque serveur pour eteindre bind si ton haproxy (ou tous ses backend) est down pour ne plus servir la mauvaise IP. On 03/03/2020 11:15, Mickael Hubert wrote: Bonjour à tous, nous devons réaliser du HA (et si possible du loadbalancing) entre 2 instances HAProxy, ces 2 Haproxy doivent-être hébergés dans 2 DC différents. Pas possible de réaliser du VRRP car nous ne pouvons pas switcher l'IP publique de l'un à l'autre des DC. La solution la plus simple serait de réaliser du round robin DNS pour pointer sur les 2 IP publiques des 2 HAproxy. Mais avant de se lancer tête baissée dans le truc, je souhaitais savoir si vous auriez d'autre solutions à me proposer ? Car à ma connaissance, si un des HAProxy est HS, le DNS n'en saura rien et continuera à balancer du trafic dessus (avec 50% d'échec). Merci d'avance pour votre aide ! ++ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] HAProxy multi DC
Bonjour Mickael, As tu la possibilité de mettre en place deux sessions BGP entre tes HAProxy et les routeurs de ton opérateur/hébergeur et d'annoncer la même IP (flotante) des deux cotés qui servira à ta prod ? Avec cette solution tu peux même monitorer ton process HAPROXY et de shut/no shut ta session BGP selon l'état de celui-ci --- Jugurta Yennek Le 2020-03-03 11:15, Mickael Hubert a écrit : Bonjour à tous, nous devons réaliser du HA (et si possible du loadbalancing) entre 2 instances HAProxy, ces 2 Haproxy doivent-être hébergés dans 2 DC différents. Pas possible de réaliser du VRRP car nous ne pouvons pas switcher l'IP publique de l'un à l'autre des DC. La solution la plus simple serait de réaliser du round robin DNS pour pointer sur les 2 IP publiques des 2 HAproxy. Mais avant de se lancer tête baissée dans le truc, je souhaitais savoir si vous auriez d'autre solutions à me proposer ? Car à ma connaissance, si un des HAProxy est HS, le DNS n'en saura rien et continuera à balancer du trafic dessus (avec 50% d'échec). Merci d'avance pour votre aide ! ++ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] HAProxy multi DC
Ca doit pas être impossible de détecter qu’un HA est mort et de mettre à jour la zone DNS automatiquement (elle devra avoir un TTL faible bien sûr, je sais c’est mal) ? Ca me semble KISS non ? > Le 3 mars 2020 à 11:15, Mickael Hubert a écrit : > > Bonjour à tous, > nous devons réaliser du HA (et si possible du loadbalancing) entre 2 > instances HAProxy, ces 2 Haproxy doivent-être hébergés dans 2 DC différents. > Pas possible de réaliser du VRRP car nous ne pouvons pas switcher l'IP > publique de l'un à l'autre des DC. > > La solution la plus simple serait de réaliser du round robin DNS pour > pointer sur les 2 IP publiques des 2 HAproxy. Mais avant de se lancer tête > baissée dans le truc, je souhaitais savoir si vous auriez d'autre solutions > à me proposer ? > Car à ma connaissance, si un des HAProxy est HS, le DNS n'en saura rien et > continuera à balancer du trafic dessus (avec 50% d'échec). > > Merci d'avance pour votre aide ! > > ++ > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] HAProxy multi DC
Bonjour à tous, nous devons réaliser du HA (et si possible du loadbalancing) entre 2 instances HAProxy, ces 2 Haproxy doivent-être hébergés dans 2 DC différents. Pas possible de réaliser du VRRP car nous ne pouvons pas switcher l'IP publique de l'un à l'autre des DC. La solution la plus simple serait de réaliser du round robin DNS pour pointer sur les 2 IP publiques des 2 HAproxy. Mais avant de se lancer tête baissée dans le truc, je souhaitais savoir si vous auriez d'autre solutions à me proposer ? Car à ma connaissance, si un des HAProxy est HS, le DNS n'en saura rien et continuera à balancer du trafic dessus (avec 50% d'échec). Merci d'avance pour votre aide ! ++ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Is the Internet Resilient Enough to Withstand Coronavirus?
Après la penurie de masques, de gel hydro et la hausse de prix de ces produits sur Amazon, les providers internet vont-ils eux aussi augmenter leurs prix pour supporter la charge virale/flix ? Dredi c'est tout les jours face à la bêtise. Le 3 mars 2020 08:52:26 GMT+01:00, Laurent Fabre a écrit : >C’est HS et pas Dredi et pas Misc >Mais je ne fais que réagir sur un sujet d’actualité... > >Pour ce qui est d’attaquer les organes reproductifs, ce n’est pas lié >au corona virus qui s’attaque aux bronches et pas au corones ! > >La nocivité de la 4G, c’est les ondes qui vous frient les glandes à >petit feux ! >Pour éviter cela, il faut réduire le DAS (Dégât Au Sexe) >Pour ça, une solution : le Lora ! >(Long Orgasme Régulièrement Administré) > >Laurent-Charles FABRE >Envoyé depuis mon mobile > > >> Le 2 mars 2020 à 18:11, Michel Py > a écrit : >> >> >>> >>> Stephane Bortzmeyer a écrit : >>> Vérifiez vos infras, et surtout votre peering avec Netflix : >>> >https://www.internetsociety.org/blog/2020/02/is-the-internet-resilient-enough-to-withstand-coronavirus/ >> >> C'est très dangereux cette tendance, çà va faciliter le risque de >mutation du virus qui va bientôt se propager à travers 4G et provoquer >la stérilité de l'espèce humaine en attaquant les organes reproductifs. >> >> Michel. >> >> >> --- >> Liste de diffusion du FRnOG >> http://www.frnog.org/ > > >--- >Liste de diffusion du FRnOG >http://www.frnog.org/ -- Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté. --- Liste de diffusion du FRnOG http://www.frnog.org/
