RE: [FRnOG] [MISC] le pétaoctet du pauvre
> Hervé BRY a écrit : > Ici on a du HGST Data60 > (https://www.westerndigital.com/products/storage-platforms/ultrastar-data60-hybrid-platform), > qui est vraiment bien foutu niveau maintenance. C'est redondant niveau alim > et switch SAS, ce > qui permet bien entendu le SAS double attachement (pour la redondance ou le > doublement du débit). La redondance au niveau alim et SAS faut être fou pour pas faire, IMHO. Est-ce que tu peux mesurer la température des disques individuellement ? C'est plutôt lié au logiciel qu'au boitier (FreeNAS le fait); je serais curieux de connaitre la différence de température entre le l'avant et le l'arrière. Oh là là le modèle à 102 disques, plus d'un mètre de profondeur; l'arrière doit être un four. Même question pour le Dell. > L'inconvénient de ces châssis de 60 disques et plus c'est la profondeur: il > faut les baies adaptées sans quoi tu n'as plus de places pour les câbles ou > pour fermer la porte :) Sans parler du poids : ceux qui ont le changement par le dessus, quand il faut les tirer de 50 cm ou même 1 m pour remplacer un disque qui est dans la dernière rangée, vaut mieux que les rails tiennent le coup et que la baie soit solidement ancrée au sol, sinon c'est tilt game over. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] HAProxy multi DC
Re, > 1. le client JS fait sa requête DoH > 2. il voit 3 CNAMEs : srv[1,2,3].frnog.org > 3. il fait son LB façon RR-DNS et chosit srv2.frnog.org 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)... > 1. _chicken & egg _: comment s'assurer qu'on puisse bien charger le JS > initial alors que les noms de domaine utilisés peuvent ne pas > répondre par un mapping DNS classique (c'est bien le problème qu'on > cherche à résoudre) Le static est sur N x CDNs avec un RR DNS... aucun soucis. > 2. _same origin_ : ... Pas un soucis. > 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) Oui. > 4. _latence DNS_ : à benchmarker (DoH en JS à l'origine vs. DNS > classique via des resolvers qui cachent) > > Intéressé(s) à poursuivre l'étude ? Faudrait clairement faire un PoC... 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] HAProxy multi DC
Oui, voilà ! Donc en résumé, pour accéder à http[s]://www.frnog.org/... 1. le client JS fait sa requête DoH 2. il voit 3 CNAMEs : srv[1,2,3].frnog.org 3. il fait son LB façon RR-DNS et chosit srv2.frnog.org 4. il poursuit en accédant à http:[s]://srv2.frnog.org/... Problèmes à résoudre : 1. _chicken & egg _: comment s'assurer qu'on puisse bien charger le JS initial alors que les noms de domaine utilisés peuvent ne pas répondre par un mapping DNS classique (c'est bien le problème qu'on cherche à résoudre) 2. _same origin_ : le site doit être conçu pour autoriser les contenus de http:[s]://srv*.frnog.org/ comme ceux de http[s]://www.frnog.org/. C'est un problème classique, voir domain= pour les cookies par exemple 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) 4. _latence DNS_ : à benchmarker (DoH en JS à l'origine vs. DNS classique via des resolvers qui cachent) Intéressé(s) à poursuivre l'étude ? Le 05/03/2020 à 19:41, Philippe Bourcier a écrit : > Re, > >> Ou alors tu te comportes comme une adulte et tu utilises des noms DNS >> statiques, un par machine. >> >> Franchement, arretez avec l'utilisation des IP dans les applis. Ce n'est pas >> comme ca que les >> choses sont supposes marcher. > Mais ouai en fait... tu peux très bien faire une requête DoH en IN CNAME sur > un host et attendre un résultat multiple à la requête... > > Genre : > IN CNAME api.frnog.org > => srv1.frnog.org > => srv2.frnog.org > ... > > Et du coup tu gardes le nom de domaine pour tes requêtes HTTPS suivantes (et > donc pas de problèmes de cookies, etc.). > On va y arriver à faire ce LB.js :) > > > Cordialement, > -- > Philippe Bourcier > web : http://sysctl.org/ > blog : https://www.linkedin.com/today/author/philippebourcier > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] HAProxy multi DC
Re, > Ou alors tu te comportes comme une adulte et tu utilises des noms DNS > statiques, un par machine. > > Franchement, arretez avec l'utilisation des IP dans les applis. Ce n'est pas > comme ca que les > choses sont supposes marcher. Mais ouai en fait... tu peux très bien faire une requête DoH en IN CNAME sur un host et attendre un résultat multiple à la requête... Genre : IN CNAME api.frnog.org => srv1.frnog.org => srv2.frnog.org ... Et du coup tu gardes le nom de domaine pour tes requêtes HTTPS suivantes (et donc pas de problèmes de cookies, etc.). On va y arriver à faire ce LB.js :) 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] [MISC] le pétaoctet du pauvre
Le sam. 29 févr. 2020 à 19:53, Michel Py a écrit : > J'ai des MDS 600 : > https://support.hpe.com/hpesc/public/docDisplay?docId=emr_na-c01671885 > 70 disques chacun, plein d'emmerdes. Mécaniquement c'est naze. Ici on a du HGST Data60 ( https://www.westerndigital.com/products/storage-platforms/ultrastar-data60-hybrid-platform), qui est vraiment bien foutu niveau maintenance. C'est redondant niveau alim et switch SAS, ce qui permet bien entendu le SAS double attachement (pour la redondance ou le doublement du débit). On peut les avoir à bon prix, en particulier en les achetant directement rempli de disques. J'ai aussi du Dell MD3060e, qu'on peut trouver à pas trop cher en occase ( https://www.ebay.fr/itm/Dell-PowerVault-MD3060e-No-Hard-Drives-Installed/283707897219?hash=item420e4ef583:g:cqEAAOSw0K5d8gdD ). L'approche est un peu moins pratique, je trouve, mais tout est aussi redondant. L'inconvénient de ces châssis de 60 disques et plus c'est la profondeur: il faut les baies adaptées sans quoi tu n'as plus de places pour les câbles ou pour fermer la porte :) Hervé BRY Administrateur Système Geneanet (http://www.geneanet.org) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] HAProxy multi DC
> Testé à l'instant sous Windows 10, le timeout est de l'ordre de 20 > secondes. Que ce soit sur Chrome, Firefox ou Edgium. > Donc ça reste acceptable... > Oui. Précisément : 21 s de timeout minimum dans cette config. Mais ça dépend de la machine, de l'OS, des patches et du "sysconfig" local. On voit 21 s pour une config typique de desktop ou serveur avec 3 retries TCP max (+un délai initial de 3 s et un algo de backoff en x2), mais sur un mobile, le nombre de retries max est plutôt porté à 5 à cause de la perte de paquets. Cela donne alors un timeout minimum à plus de 1 minute 30 : * t0 : SYN * t0 +3 s : pas de réponbse au SYN, retry avec doublement du délai à 6 s * t0 + 9 s : 2ème retry, doublement du délai à 12 s * *t0 + 21 s* : 3ème retry, délai à 24 s <== cas typique * t0 + 45 s : 4ème retry, délai à 48 s * t0 + 93 s : abandon au 5ème retries <== worst case et ça, c'est au mieux, en supposant que l'appli réagisse dès le timeout connect TCP. C'est pour ça que je disais que le RR-DNS sert au load balancing, mais pas à la redondance. --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] Cisco, table MAC, cache ARP, et autres chinoiseries
> Eric Belhomme a écrit : > j'ai donc acheté une caméra POE sur aliexpress. C'est quel modèle, que personne achète la même daube ? Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [BIZ] Achat ip publique
> Stéphane Cannesson a écrit : > Auriez-vous un contact sûr pour acheter des ip publiques ? Il me faudrait un > /20, quelques > cotations déjà auprès de brokers présents sur le portail du ripe, mais vu le > montant, si > vous avez des sociétés avec lesquelles vous travaillez et de confiance, > n'hésitez pas a me > faire suivre. Beaucoup en vendent, mais les bons vendeurs restent a trouver :) Perso je suis satisfait de https://auctions.ipv4.global/. J'en ai acheté il y a 2 ans. Pour un /20 c'est $20 par IP soit 17.89€ J'ai pas d'actions, je connais personne, mais çà a marché pour moi dans le passé. Faut parler Anglais un minimum, quoi que le jargon légal c'est plutôt du Chinois. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] HAProxy multi DC
Le 05/03/2020 à 00:50, Jonathan Leroy - Inikup via frnog a écrit : > Donc oui, les cookies sont nécessaires en 2020. :) +1. Ne pas confondre cookies permanents (le MAL) et cookies de session (une nécessité en 2020 et pour longtemps encore). D'ailleurs, le fait qu'un contenu en http://IP/... ne puisse pas accéder aux cookies de session de http://FQDN/... c'est normal et voulu. D'où la question sur DoH dans le browser. --- 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] Cisco, table MAC, cache ARP, et autres chinoiseries
Le 05/03/2020 à 10:46, David Ponzone a écrit :
oh la vache, le coup-bas:)
Alors déjà moi, j’ai pas vraiment sollicité de temps sur un problème réseau,
sans filer ma conf:)
Et puis le but correspond à un besoin puisque le NAS enfin fabriqué est plus
puissant qu’un NAS commercial 2 fois plus cher, ta caméra à 20€ peut-elle en
dire autant ?:)
Pas un coup bas, juste un clin d'oeil entres adeptes de la bricole et du
DIY :D
Quant à ma conf, il s'agit de mon "lab à moi que j'ai" dans ma cave,
j'en ai un peu rien à braire que le Monde sache que j'ai 4 VLAN qui se
battent en duel avec un plan d'adressage en 172.16.80.0/21 derrière ma
freebox :p Et tu noteras tout de même que j'ai pris soin de virer mes
secrets ('blablabla', ce n'est pas un mot de passe !) La sécurité par
l'obscurité, ce n'est pas un bon modèle ;)
Et un ping depuis le switch, ça marche mieux ?
Sinon, remplace la cam par un PC avec la même IP.
Si ça marche, tu jettes la caméra (tu peux éventuellement vérifier s’il y a pas
un upgrade à faire, car souvent les produits chinois de ce type restent 2 ans
dans un vieux stock dont personne ne veut, jusqu’à ce que Alitruc réussisse à
les fourguer.à un gogo (ça c’est toi)
Comme répondu à Dominique, la cam va partir à la benne et je vais partir
un chasse d'une caméra dôme + IR digne de ce nom. Il faut savoir
reconnaitre ses echecs ;)
--
Rico
---
Liste de diffusion du FRnOG
http://www.frnog.org/
Re: [FRnOG] [TECH] Cisco, table MAC, cache ARP, et autres chinoiseries
Je suis déçu, je trouve que tu baisses les bras un peu vite. Y a des modèles qu’il faut secouer pendant 10 sec pour le reset usine. Essaie. > Le 5 mars 2020 à 12:43, Eric Belhomme (FRnOG) a > écrit : > > Je laisse tomber, j'ai ouvert un litige sur aliexpress. Comme l'a fort > justement fait remarquer David, le jeu n'en vaut pas la chandelle ;) > > -- > Rico > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Cisco, table MAC, cache ARP, et autres chinoiseries
À tout hasard : - as-tu essayé de ping vers l'ip 192.168.1.10 depuis qu'elle ne "fonctionne plus" ? - pas vu passer le fait que tu aies essayé de la réinitialiser en config usine ; si c'est vraiment parceque le mode DHCP ne fonctionne pas, tu reset et mets en statique. Oui, j'ai bien tenté de retaper sur son IP "usine", ça na rien donné. J'ai aussi tenté de la brancher direct au cul d'un laptop, sans POE, même résultats... Pour la conf usine, c'est là que vous allez rigoler... Y'a pas de bouton "reset to factory defaults" ! Me disant que c'était pas possible, qu'ils avaient dû le planquer à l'intérieur, je l'ai désossé : rien, nada, que pouic ! pas le moindre bouton, ou jumper, ou même seulement des touches de contacts directement sur le PCB ! Même pas vu un truc qui ressemblerait de près ou de loin à du JTAG, c'est à se demander /comment/ ils flashent leur firmware de merde sur cette cam ??? Je laisse tomber, j'ai ouvert un litige sur aliexpress. Comme l'a fort justement fait remarquer David, le jeu n'en vaut pas la chandelle ;) -- Rico --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] HAProxy multi DC
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/
--
Théophile Helleboid
---
Liste de diffusion du FRnOG
http://www.frnog.org/
Re: [FRnOG] [TECH] Cisco, table MAC, cache ARP, et autres chinoiseries
Le Thu, Mar 05, 2020 at 09:30:09AM +0100, Eric Belhomme (FRnOG) [rico-fr...@ricozome.net] a écrit: > Bonjour la liste, [...] > rien de plus que du trafic ARP. Ce qui explique les entrées au > niveau du switch. Par contre aucun trafic DHCP ou BOOTP. Pourtant la > cam me ressort l'IP que mon dhcpd est sensé lui attribuer. Il a donc > dû stocker ça quelque part dans une NVRAM. Bref, j'en arrive à la > conclusion que la stack DHCP de cette cam pue grave du fion, ce qui > explique pourquoi dans la doc succincte fournie avec la cam ils > spécifient "We do not recommand leaving the IP camera on DHCP" (en > config usine elle est en 192.168.1.10/24 statique) À tout hasard : - as-tu essayé de ping vers l'ip 192.168.1.10 depuis qu'elle ne "fonctionne plus" ? - pas vu passer le fait que tu aies essayé de la réinitialiser en config usine ; si c'est vraiment parceque le mode DHCP ne fonctionne pas, tu reset et mets en statique. -- Dominique Rousseau Neuronnexion, Prestataire Internet & Intranet 6 rue des Hautes cornes - 8 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [BIZ] Achat ip publique
Bonjour, Auriez-vous un contact sûr pour acheter des ip publiques ? Il me faudrait un /20, quelques cotations déjà auprès de brokers présents sur le portail du ripe, mais vu le montant, si vous avez des sociétés avec lesquelles vous travaillez et de confiance, n'hésitez pas a me faire suivre. Beaucoup en vendent, mais les bons vendeurs restent a trouver :) Par avance, merci --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] HAProxy multi DC
Je crois que l'on a mélangé un peu plusieurs discussions mais au final on en revient toujours au même débat : ou placer la redondance ? coté infra ou coté applicatif ? La redondance infrastructure est d'une certaine manière plus facile à réaliser mais moins efficace ou plus dure à mettre au point. La redondance coté client est sans doute très intéressante si l'on accepte de passer du temps coté client. C'est vrai pour qu'une page web, on peut sans doute trouver des solutions intéressantes avec les possibilités de bricoler en js actuelle. Une squelette statique délivré via un CDN (avec un peu de cache), du js qui fait des checks sur les différents serveurs de ressources, construction de la page après. Ça doit se faire. Même pas besoin de DoH en fait. D'ailleurs DoH coté client js, why not, mais après il faudrait pouvoir faire comprendre au browser qu'il doit utiliser ce qui vient d’être résolu pour le reste, ce qui est peut être possible mais je ne sais pas comment faire. Ca serait intéressant de faire un POC la dessus. -- Raphael Mazelier On 05/03/2020 00:50, Jonathan Leroy - Inikup via frnog wrote: Le mer. 4 mars 2020 à 23:04, Philippe Bourcier a écrit : Utiliser des cookies, en 2020 ? ... :) Web Storage, JWT, sessionless... ? Web Storage n'est pas fait pour stocker des infos de session (n'importe quel script tiers sur la page peut accéder à son contenu). JWT est une horreur à éviter à tout prix (https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid). Dans les faits le sessionless quasiment impossible pour une app web sans utiliser JWT. Donc oui, les cookies sont nécessaires en 2020. :) Pour répondre à la question initiale : - Vraie solution propre : si tu as besoin d'un failover sur un DC secondaire, c'est que ton business est critique et que toute coupure te coûte une somme non négligeable. Donc il te faut demander un /24 (ainsi qu'un /48, car nous sommes en 2020) à un LIR et l'annoncer en BGP. Ton hébergeur n'est pas capable de faire ça ? Qu'il change de métier (ou à défaut, tu peux changer d'hébergeur). - Solution pas trop sale alternative : Cloudflare propose un LB dans le cloud qui fait ça très bien et pour pas cher. Ça check les serveurs de ton pool toutes les 15 seconds et il y a même une API. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] HAProxy multi DC
On 05-Mar-2020 10:41 CET, wrote: > * Renaud RAKOTOMALALA, 2020-03-03 : > > >- t'appuyer sur un service tier pour le DNS qui en conscience adaptera > >la réponse sur le ou les IP publiques de tes HAProxy > > Ça peut être une solution assez simple à mettre en œuvre avec AWS > Route53, qui permet d'associer les RR retournés à des "health checks" > (et/ou à d'autres critères tels que des estimations de latence, si on > veut favoriser un serveur "proche", au-delà du simple partage de charge). Sinon, sans tout mettre chez AWS, PowerDNS Authoritative sait aussi faire, via les Lua Records: https://doc.powerdns.com/authoritative/lua-records/ -- Nico --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Cisco, table MAC, cache ARP, et autres chinoiseries
Bonjour Le 05/03/2020 à 10:46, David Ponzone a écrit : [...] Ubiquiti c’est bien aussi en caméra. 100€HT et NVR software gratuit. La dernière version, Protect, a un accès cloud/mobile bien mieux qu’avant. Sauf que c'est proprio et incompatible avec le monde des logiciels de surveillance. Dans l'autre sens, leur NVR ne prend que de l'ubiquiti. À oublier pour ma part. -- Daniel Huhardeaux +33.368460...@tootai.net sip:8...@sip.tootai.net +41.445532...@swiss-itech.chtootaiNET --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] HAProxy multi DC
Ca règle le problème de cache local des DNS résolveurs pendant X min ? > Le 5 mars 2020 à 10:44, Raphael Mazelier a écrit : > > Oui si on accepte d'utiliser un service tiers, un dns global type route53 est > simple (peu cher) et efficace pour ce genre de redondance. > > On 05/03/2020 10:41, Thomas Quinot wrote: >> * Renaud RAKOTOMALALA, 2020-03-03 : >> >>>- t'appuyer sur un service tier pour le DNS qui en conscience adaptera >>>la réponse sur le ou les IP publiques de tes HAProxy >> Ça peut être une solution assez simple à mettre en œuvre avec AWS >> Route53, qui permet d'associer les RR retournés à des "health checks" >> (et/ou à d'autres critères tels que des estimations de latence, si on >> veut favoriser un serveur "proche", au-delà du simple partage de charge). >> >> Thomas. >> >> >> --- >> Liste de diffusion du FRnOG >> http://www.frnog.org/ > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Cisco, table MAC, cache ARP, et autres chinoiseries
> Le 5 mars 2020 à 10:13, Eric Belhomme (FRnOG) a > écrit : > > Le 05/03/2020 à 09:43, David Ponzone a écrit : >> Ma sagesse très personnelle dit: >> >> Faut arrêter d’acheter des (mauvais) trucs chinois à 20€ sur Alibaba, pour >> finalement perdre 80€ de son temps personnel (ou des autres) à les faire >> marcher, alors qu’une cam à 100€ aurait fait le boulot direct :) > > C'est pas faux, j'ai agit sous l'impulsion d'un coup de tête... Je te dirais > bien que ça me servira de leçon, mais je n'y crois pas, et toi non plus ;) Et > puis venant de la part d'un gars qui voulait monter un NAS à coups de SBC > chinetoque y'a pas deux mois, et qui en a chié comme un Turc pour faire > tourner une carte SATA de provenance douteuse, la remarque ne manque pas de > sel ;-) oh la vache, le coup-bas :) Alors déjà moi, j’ai pas vraiment sollicité de temps sur un problème réseau, sans filer ma conf :) Et puis le but correspond à un besoin puisque le NAS enfin fabriqué est plus puissant qu’un NAS commercial 2 fois plus cher, ta caméra à 20€ peut-elle en dire autant ? :) Et il y a eu des retours de gens intéressés. Donc David 1, Eric, 0 :) Bon, plus sérieusement: >> Ceci était, à vue de nez rapide, le comportement que tu as fait penser à: >> -caméra dans le VLAN10 >> -interface IP 172.16.80.1/24 sur le catalyst pas dans le VLAN 10 > > la cam est effectivement sur le VLAN10, tout comme mon host en 172.16.80.90, > le Catalyst est bien mon routeur de "cœur de réseau" et 172.16.80.1 est bien > l'IP associée au VLAN10 sur le catalyst. > Et un ping depuis le switch, ça marche mieux ? Sinon, remplace la cam par un PC avec la même IP. Si ça marche, tu jettes la caméra (tu peux éventuellement vérifier s’il y a pas un upgrade à faire, car souvent les produits chinois de ce type restent 2 ans dans un vieux stock dont personne ne veut, jusqu’à ce que Alitruc réussisse à les fourguer.à un gogo (ça c’est toi) :) Ubiquiti c’est bien aussi en caméra. 100€HT et NVR software gratuit. La dernière version, Protect, a un accès cloud/mobile bien mieux qu’avant. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] HAProxy multi DC
Oui si on accepte d'utiliser un service tiers, un dns global type route53 est simple (peu cher) et efficace pour ce genre de redondance. On 05/03/2020 10:41, Thomas Quinot wrote: * Renaud RAKOTOMALALA, 2020-03-03 : - t'appuyer sur un service tier pour le DNS qui en conscience adaptera la réponse sur le ou les IP publiques de tes HAProxy Ça peut être une solution assez simple à mettre en œuvre avec AWS Route53, qui permet d'associer les RR retournés à des "health checks" (et/ou à d'autres critères tels que des estimations de latence, si on veut favoriser un serveur "proche", au-delà du simple partage de charge). Thomas. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] HAProxy multi DC
Nous avons plusieurs services derrières ces Haproxy, certes du web, qui ne m'inquiète pas vraiment, un downtime d'1h est acceptable... Notre coeur de business c'est la reco vocale, donc le point critique c'est notre API de reco (en websocket). Des choix stratégiques ont été fait chez un hébergeur et nous ne pouvons pas en changer (sans que cela nous coûte 2 bras, 2 jambes)... Et cet hébergeur (dont je tairais le nom), n'a pas "encore" la possibilité de switcher ses annonces BGP entre ses DC. En tout cas des solutions et infos très intéressantes ! merci Le jeu. 5 mars 2020 à 09:51, Laurent Fabre a écrit : > Hello, > > Je pensais la solution HS mais comme on propose cloudflare... > > Tu mets un 3ème HAProxy en frontal pour distribuer vers tes 2x autres LB > > HAP sait facilement tester tout les serveurs fils pour les éjecter du RRB > Si tout est en panne tu peux même servir une page d’excuse. > > La charge ? > HAProxy c’est lite et ça ne fatiguera pas avant que tu ai assez de traffic > pour te payer autre chose. > > Le débit ? > Tout les bon CMS on un plugin CDN pour gérer des url média en direct une > fois sur un des Web serveur > > Resilience du HAP frontal ? > Un nux barebone avec juste HAP, Bein ça plante pas. > En tout ça pas entre changement de noyaux ici. Et ca marche très bien en > cluster HAP > > Tu ne sais pas configurer tout ça ? > HAP est écrit par des français monsieurs. > Ils drive aussi la société ALOHA ces gens. > Support payant mais en français et conf au click > > Trop cher ALOHA ? > Soit tu aprends a le faire > Soit il existe un partenaire HAP conçurent de ALOHA pas cher. > Il y a même des graphes pour tout le cluster pour illustrer le rapport de > copil client :-) > Je ne donne pas le nom car je soutiens la Frenchtek ;-P > tip: c’est une organisation éponyme au sujet > > Sinon nous on fait du bgp et du L2 inter DC mais c’est pas BIZ ici ;-) > > My 2 cents > > Laurent-Charles FABRE > Envoyé depuis mon mobile > > > > Le 5 mars 2020 à 00:52, Jonathan Leroy - Inikup via frnog < > frnog@frnog.org> a écrit : > > > > 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. > > > > -- > > Jonathan Leroy > > > > > > --- > > 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
* Renaud RAKOTOMALALA, 2020-03-03 : >- t'appuyer sur un service tier pour le DNS qui en conscience adaptera >la réponse sur le ou les IP publiques de tes HAProxy Ça peut être une solution assez simple à mettre en œuvre avec AWS Route53, qui permet d'associer les RR retournés à des "health checks" (et/ou à d'autres critères tels que des estimations de latence, si on veut favoriser un serveur "proche", au-delà du simple partage de charge). Thomas. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Cisco, table MAC, cache ARP, et autres chinoiseries
Hello Eric, Je te conseille une Hikvision pour moins de 100EUR. C'est chinois mais beaucoup plus fiable. --- Jugurta Yennek Le 2020-03-05 09:30, Eric Belhomme (FRnOG) a écrit : Bonjour la liste, Ayant acheté une chinoiserie connectée sur un site bien connu, en l'occurrence aliexpress, je me retrouve confronté à un problème que je n'arrive pas à comprendre, et j'aurais besoin de votre science Ciscotienne, mes compétences en la matière étant somme toute quelque peu limitées. Voici le topo : j'ai donc acheté une caméra POE sur aliexpress. J'ai profité de ce dernier week-end gris pour l'installer et la brancher sur mon installation: - un injecteur Gigabit POE 802.3af/at en mode A à 4 ports, qui alimentent également mon AP WIFI (un Linksys) - un switch Cisco WS-C3560G-48TSen version 15.0(2)SE11 qui tourne sur l'image C3560-IPSERVICESK9-M Je vous passe les détails rocambolesques avec une appli (très) mal traduite du chinois pour pouvoir configurer la cam en DHCP, lui coller un mot de passe, et désactiver tout ce qui est inutile (j'ai laissé uniquement NTP et RTSP), la caméra finit donc par tomber en marche et je peux l'ajouter à mon ZoneMinder. Ca c'était dimanche. Hier, je me rends compte que ZM ne capture plus le flux RTSP de cette cam. Je me rends compte qu'en fait la cam n'est plus joignable. Je regarde donc les logs de mon dhcpd et je constate que le dernier lease date de dimanche tard dans la nuit, depuis plus rien ! Comme j'ai un switch L3 sous la main, je regarde son cache ARP, ainsi que sa table MAC: quicksilver>show interfaces status Gi0/39POE camera connected10 a-full a-100 10/100/1000BaseTX Le port est bien up quicksilver>show mac address-table Mac Address Table --- VlanMac Address TypePorts --- - ... 100012.4134.5e76DYNAMIC Gi0/39 ... la MAC de la cam est bien présente dans la table du switch, sur le port gb sur lequel je l'ai connecté quicksilver#show interfaces gi0/39 | include ARP Encapsulation ARPA, loopback not set ARP type: ARPA, ARP Timeout 04:00:00 config ARP par défaut pour un cisco quicksilver>show arp Internet 172.16.80.810 0012.4134.5e76 ARPA Vlan10 à priori, la cam a annoncé son conf IP via ARP Pourtant, pas de réponse au ping, ni sur aucun port supposément ouvert (HTTP, RTSP), nmap reste aveugle (depuis un host sur le même VLAN que la CAM) et le soft "DeviceConfig" livré avec la cam ne la voit plus lui non plus ! A court d'idée, je finis par configurer un port-mirroring sur mon port g0/39 afin de lancer une capture du trafic au boot de la cam. Voici ce que j'obtiens: No. Time Source Destination Protocol Length Info 6 58.060403 a2imarke_34:5e:76 Broadcast ARP 60 Who has 172.16.80.1? Tell 172.16.80.81 Frame 6: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) Ethernet II, Src: a2imarke_34:5e:76 (00:12:41:34:5e:76), Dst: Broadcast (ff:ff:ff:ff:ff:ff) Address Resolution Protocol (request) No. Time Source Destination Protocol Length Info 7 59.059478 a2imarke_34:5e:76 Broadcast ARP 60 Who has 172.16.80.1? Tell 172.16.80.81 Frame 7: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) Ethernet II, Src: a2imarke_34:5e:76 (00:12:41:34:5e:76), Dst: Broadcast (ff:ff:ff:ff:ff:ff) Address Resolution Protocol (request) No. Time Source Destination Protocol Length Info 8 60.059471 a2imarke_34:5e:76 Broadcast ARP 60 Who has 172.16.80.1? Tell 172.16.80.81 Frame 8: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) Ethernet II, Src: a2imarke_34:5e:76 (00:12:41:34:5e:76), Dst: Broadcast (ff:ff:ff:ff:ff:ff) Address Resolution Protocol (request) No. Time Source Destination Protocol Length Info 18 88.820063 a2imarke_34:5e:76 Broadcast ARP 60 ARP Announcement for 172.16.80.81 Frame 18: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) Ethernet II, Src: a2imarke_34:5e:76 (00:12:41:34:5e:76), Dst: Broadcast (ff:ff:ff:ff:ff:ff) Address Resolution Protocol (ARP Announcement) rien de plus que du trafic ARP. Ce qui explique les entrées au niveau du switch. Par contre aucun trafic DHCP ou BOOTP. Pourtant la cam me ressort l'IP que mon dhcpd est sensé lui attribuer. Il a donc dû stocker ça quelque part dans une NVRAM. Bref, j'en arrive à la conclusion que la stack DHCP de cette cam pue grave du fion, ce qui explique pourquoi dans la doc succincte fournie avec la cam ils spécifient "We do not recommand leaving the IP camera on DHCP" (en config usine elle est en 192.168.1.10/24 statique) Quand je tente de pinger cette saleté de cam, voici ce que j'obtiens en capture: No. Time Source Destination Protocol Length Info 1 0.00 ASUSTekC_c4:19:e3 Broadc
Re: [FRnOG] [TECH] Cisco, table MAC, cache ARP, et autres chinoiseries
On Thu, Mar 5, 2020, at 09:30, Eric Belhomme (FRnOG) wrote: > mon host source 172.16.80.90 fait une requête ARP pour obtenir la MAC de > la cam, mais personne ne lui répond ! Pourtant, on l'a vu, le switch a > bien connaissance dans sa table ARP de 172.16.80.81 ! Il y a là quelque > chose qui me dépasse et j'en appelle à votre sagacité... > Ce n'est pas le switch, mais la cam (avec une stack IP en carton mouille) elle-meme qui doit repondre aux requetes ARP qui lui sont destinnes. Et pour toute personne qui veur repondre avec "oui, mais proxy-arp sur le switch L3", non, ce n'est pas un des cas d'usage recommandes pour ca. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Double connexion internet
Pour moins cher, même un 80C ferait l'affaire pour une prise en main (ou un 80CM pour la partie wifi, mais c'est pas ce qu'ils font de mieux), et il se met à jour en 5.6 pour avoir accès à une interface "moderne". Le mer. 4 mars 2020 à 14:40, Guillaume Barrot a écrit : > un Fortigate 30E au broke est même suffisant, et sera moins cher. > > Le mar. 3 mars 2020 à 16:55, GUILLAUME Cyrille > > a écrit : > > > 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/ > > > > > -- > Cordialement, > > Guillaume BARROT > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Cisco, table MAC, cache ARP, et autres chinoiseries
Le 05/03/2020 à 09:43, David Ponzone a écrit : Ma sagesse très personnelle dit: Faut arrêter d’acheter des (mauvais) trucs chinois à 20€ sur Alibaba, pour finalement perdre 80€ de son temps personnel (ou des autres) à les faire marcher, alors qu’une cam à 100€ aurait fait le boulot direct :) C'est pas faux, j'ai agit sous l'impulsion d'un coup de tête... Je te dirais bien que ça me servira de leçon, mais je n'y crois pas, et toi non plus ;) Et puis venant de la part d'un gars qui voulait monter un NAS à coups de SBC chinetoque y'a pas deux mois, et qui en a chié comme un Turc pour faire tourner une carte SATA de provenance douteuse, la remarque ne manque pas de sel ;-) Ceci était, à vue de nez rapide, le comportement que tu as fait penser à: -caméra dans le VLAN10 -interface IP 172.16.80.1/24 sur le catalyst pas dans le VLAN 10 la cam est effectivement sur le VLAN10, tout comme mon host en 172.16.80.90, le Catalyst est bien mon routeur de "cœur de réseau" et 172.16.80.1 est bien l'IP associée au VLAN10 sur le catalyst. Sans la conf complète du Catalyst, c’est pas simple, et y a rien à gagner en plus :) Je ne voulais pas polluer la liste avec 200 lignes de fichier de conf, mais puisque tu demandes... et pour la carotte, ma gratitude éternelle, ça compte ? :D version 15.0 no service pad service timestamps debug datetime service timestamps log datetime no service password-encryption ! hostname quicksilver ! boot-start-marker boot-end-marker ! ! enable secret 5 blablabla enable password blablabla ! username admin password 0 blablabla aaa new-model ! aaa session-id common clock timezone CET 1 0 clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00 system mtu routing 1500 ip routing no ip cef optimize neighbor resolution ip domain-name ricolan ip name-server 172.16.81.10 ! ip multicast-routing distributed ! crypto pki trustpoint blablabla ! spanning-tree mode pvst spanning-tree extend system-id ! vlan internal allocation policy ascending ! ip ssh logging events ip ssh version 2 ip ssh pubkey-chain username blablabla ! interface GigabitEthernet0/6 description bureau - desktop eric switchport access vlan 10 switchport mode access ! interface GigabitEthernet0/39 description POE camera switchport access vlan 10 switchport mode access ! interface GigabitEthernet0/47 ! interface Vlan1 no ip address shutdown ! interface Vlan2 description interconnect ip address 172.16.87.254 255.255.255.252 ! interface Vlan10 description workstations ip address 172.16.80.1 255.255.255.0 ip helper-address 172.16.81.10 ip pim sparse-dense-mode ! interface Vlan11 description servers ip address 172.16.81.1 255.255.255.0 ! interface Vlan12 description wifi ip address 172.16.82.1 255.255.255.0 ip helper-address 172.16.81.10 ip pim sparse-dense-mode ! interface Vlan13 description sandbox ip address 172.17.0.1 255.255.255.0 ! interface Vlan20 ip address 172.16.83.1 255.255.255.0 ! interface Vlan30 no ip address ! no ip http server no ip http secure-server ! ip pim send-rp-announce Vlan10 scope 5 ip pim send-rp-announce Vlan12 scope 5 ip pim send-rp-discovery scope 5 ip route 0.0.0.0 0.0.0.0 172.16.87.253 ip route 172.16.86.0 255.255.255.0 172.16.87.253 ip route 192.168.16.0 255.255.255.0 172.16.80.5 ip route 192.168.27.0 255.255.255.0 172.16.87.253 ! logging host 172.16.81.13 transport tcp port 514 ! snmp-server community blablabla RO ! vstack ! line con 0 line vty 0 password blablabla transport input telnet line vty 1 4 password blablabla transport input ssh line vty 5 10 password blablabla transport input ssh line vty 11 15 password blablabla ! monitor session 1 source interface Gi0/39 monitor session 1 destination interface Gi0/47 ntp server 172.16.81.2 prefer version 2 ntp server mafreebox.freebox.fr prefer version 2 end Je n'ai laissé que les interfaces qui entrent en jeu: - g0/6 : mon host source en 172.16.80.90/24, sur le VLAN10 sur lequel tourne une Debian -g0/39: l'interface sur laquelle est conectée la cam, sur le VLAN10 - g0/47 : une interface non utilisée que j'ai configuré en mirroring du port g0/39 pour les captures (les captures ont été faites sur une interface non utilisée de mon FW à coups de tcpdump) Mon serveur DHCP est sur le VLAN11 (172.16.81.10) -- Rico --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] HAProxy multi DC
Hello, Je pensais la solution HS mais comme on propose cloudflare... Tu mets un 3ème HAProxy en frontal pour distribuer vers tes 2x autres LB HAP sait facilement tester tout les serveurs fils pour les éjecter du RRB Si tout est en panne tu peux même servir une page d’excuse. La charge ? HAProxy c’est lite et ça ne fatiguera pas avant que tu ai assez de traffic pour te payer autre chose. Le débit ? Tout les bon CMS on un plugin CDN pour gérer des url média en direct une fois sur un des Web serveur Resilience du HAP frontal ? Un nux barebone avec juste HAP, Bein ça plante pas. En tout ça pas entre changement de noyaux ici. Et ca marche très bien en cluster HAP Tu ne sais pas configurer tout ça ? HAP est écrit par des français monsieurs. Ils drive aussi la société ALOHA ces gens. Support payant mais en français et conf au click Trop cher ALOHA ? Soit tu aprends a le faire Soit il existe un partenaire HAP conçurent de ALOHA pas cher. Il y a même des graphes pour tout le cluster pour illustrer le rapport de copil client :-) Je ne donne pas le nom car je soutiens la Frenchtek ;-P tip: c’est une organisation éponyme au sujet Sinon nous on fait du bgp et du L2 inter DC mais c’est pas BIZ ici ;-) My 2 cents Laurent-Charles FABRE Envoyé depuis mon mobile > Le 5 mars 2020 à 00:52, Jonathan Leroy - Inikup via frnog a > écrit : > > 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. > > -- > Jonathan Leroy > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Cisco, table MAC, cache ARP, et autres chinoiseries
Ma sagesse très personnelle dit: Faut arrêter d’acheter des (mauvais) trucs chinois à 20€ sur Alibaba, pour finalement perdre 80€ de son temps personnel (ou des autres) à les faire marcher, alors qu’une cam à 100€ aurait fait le boulot direct :) Ceci était, à vue de nez rapide, le comportement que tu as fait penser à: -caméra dans le VLAN10 -interface IP 172.16.80.1/24 sur le catalyst pas dans le VLAN 10 Sans la conf complète du Catalyst, c’est pas simple, et y a rien à gagner en plus :) > Le 5 mars 2020 à 09:30, Eric Belhomme (FRnOG) a > écrit : > > Bonjour la liste, > > Ayant acheté une chinoiserie connectée sur un site bien connu, en > l’occurrence aliexpress, je me retrouve confronté à un problème que je > n'arrive pas à comprendre, et j'aurais besoin de votre science Ciscotienne, > mes compétences en la matière étant somme toute quelque peu limitées. > > Voici le topo : j'ai donc acheté une caméra POE sur aliexpress. J'ai profité > de ce dernier week-end gris pour l'installer et la brancher sur mon > installation: > > - un injecteur Gigabit POE 802.3af/at en mode A à 4 ports, qui alimentent > également mon AP WIFI (un Linksys) > > - un switch Cisco WS-C3560G-48TSen version 15.0(2)SE11 qui tourne sur l'image > C3560-IPSERVICESK9-M > > Je vous passe les détails rocambolesques avec une appli (très) mal traduite > du chinois pour pouvoir configurer la cam en DHCP, lui coller un mot de > passe, et désactiver tout ce qui est inutile (j'ai laissé uniquement NTP et > RTSP), la caméra finit donc par tomber en marche et je peux l'ajouter à mon > ZoneMinder. Ca c'était dimanche. > > Hier, je me rends compte que ZM ne capture plus le flux RTSP de cette cam. Je > me rends compte qu'en fait la cam n'est plus joignable. Je regarde donc les > logs de mon dhcpd et je constate que le dernier lease date de dimanche tard > dans la nuit, depuis plus rien ! > > Comme j'ai un switch L3 sous la main, je regarde son cache ARP, ainsi que sa > table MAC: > > quicksilver>show interfaces status > > Gi0/39POE camera connected10 a-full a-100 > 10/100/1000BaseTX > > Le port est bien up > > quicksilver>show mac address-table > Mac Address Table > --- > > VlanMac Address TypePorts > --- - > ... > 100012.4134.5e76DYNAMIC Gi0/39 > ... > > la MAC de la cam est bien présente dans la table du switch, sur le port gb > sur lequel je l'ai connecté > > quicksilver#show interfaces gi0/39 | include ARP > Encapsulation ARPA, loopback not set > ARP type: ARPA, ARP Timeout 04:00:00 > > config ARP par défaut pour un cisco > > quicksilver>show arp > Internet 172.16.80.810 0012.4134.5e76 ARPA Vlan10 > > à priori, la cam a annoncé son conf IP via ARP > > Pourtant, pas de réponse au ping, ni sur aucun port supposément ouvert (HTTP, > RTSP), nmap reste aveugle (depuis un host sur le même VLAN que la CAM) et le > soft "DeviceConfig" livré avec la cam ne la voit plus lui non plus ! > > A court d'idée, je finis par configurer un port-mirroring sur mon port g0/39 > afin de lancer une capture du trafic au boot de la cam. Voici ce que > j'obtiens: > > No. Time Source Destination Protocol Length Info > 6 58.060403 a2imarke_34:5e:76 Broadcast ARP 60 > Who has 172.16.80.1? Tell 172.16.80.81 > > Frame 6: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) > Ethernet II, Src: a2imarke_34:5e:76 (00:12:41:34:5e:76), Dst: Broadcast > (ff:ff:ff:ff:ff:ff) > Address Resolution Protocol (request) > > No. Time Source Destination Protocol Length Info > 7 59.059478 a2imarke_34:5e:76 Broadcast ARP 60 > Who has 172.16.80.1? Tell 172.16.80.81 > > Frame 7: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) > Ethernet II, Src: a2imarke_34:5e:76 (00:12:41:34:5e:76), Dst: Broadcast > (ff:ff:ff:ff:ff:ff) > Address Resolution Protocol (request) > > No. Time Source Destination Protocol Length Info > 8 60.059471 a2imarke_34:5e:76 Broadcast ARP 60 > Who has 172.16.80.1? Tell 172.16.80.81 > > Frame 8: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) > Ethernet II, Src: a2imarke_34:5e:76 (00:12:41:34:5e:76), Dst: Broadcast > (ff:ff:ff:ff:ff:ff) > Address Resolution Protocol (request) > > No. Time Source Destination Protocol Length Info > 18 88.820063 a2imarke_34:5e:76 Broadcast ARP 60 > ARP Announcement for 172.16.80.81 > > Frame 18: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) > Ethernet II, Src: a2imarke_34:5e:76 (00:12:41:34:5e:76), Dst: Broadcast > (ff:ff:ff:ff:ff:ff) > Address Resolution Protocol (ARP Announcement) > > rien de plus que du trafic ARP. Ce qui explique les entrées au niveau du > switch.
[FRnOG] [TECH] Cisco, table MAC, cache ARP, et autres chinoiseries
Bonjour la liste, Ayant acheté une chinoiserie connectée sur un site bien connu, en l’occurrence aliexpress, je me retrouve confronté à un problème que je n'arrive pas à comprendre, et j'aurais besoin de votre science Ciscotienne, mes compétences en la matière étant somme toute quelque peu limitées. Voici le topo : j'ai donc acheté une caméra POE sur aliexpress. J'ai profité de ce dernier week-end gris pour l'installer et la brancher sur mon installation: - un injecteur Gigabit POE 802.3af/at en mode A à 4 ports, qui alimentent également mon AP WIFI (un Linksys) - un switch Cisco WS-C3560G-48TSen version 15.0(2)SE11 qui tourne sur l'image C3560-IPSERVICESK9-M Je vous passe les détails rocambolesques avec une appli (très) mal traduite du chinois pour pouvoir configurer la cam en DHCP, lui coller un mot de passe, et désactiver tout ce qui est inutile (j'ai laissé uniquement NTP et RTSP), la caméra finit donc par tomber en marche et je peux l'ajouter à mon ZoneMinder. Ca c'était dimanche. Hier, je me rends compte que ZM ne capture plus le flux RTSP de cette cam. Je me rends compte qu'en fait la cam n'est plus joignable. Je regarde donc les logs de mon dhcpd et je constate que le dernier lease date de dimanche tard dans la nuit, depuis plus rien ! Comme j'ai un switch L3 sous la main, je regarde son cache ARP, ainsi que sa table MAC: quicksilver>show interfaces status Gi0/39 POE camera connected 10 a-full a-100 10/100/1000BaseTX Le port est bien up quicksilver>show mac address-table Mac Address Table --- Vlan Mac Address Type Ports --- - ... 10 0012.4134.5e76 DYNAMIC Gi0/39 ... la MAC de la cam est bien présente dans la table du switch, sur le port gb sur lequel je l'ai connecté quicksilver#show interfaces gi0/39 | include ARP Encapsulation ARPA, loopback not set ARP type: ARPA, ARP Timeout 04:00:00 config ARP par défaut pour un cisco quicksilver>show arp Internet 172.16.80.81 0 0012.4134.5e76 ARPA Vlan10 à priori, la cam a annoncé son conf IP via ARP Pourtant, pas de réponse au ping, ni sur aucun port supposément ouvert (HTTP, RTSP), nmap reste aveugle (depuis un host sur le même VLAN que la CAM) et le soft "DeviceConfig" livré avec la cam ne la voit plus lui non plus ! A court d'idée, je finis par configurer un port-mirroring sur mon port g0/39 afin de lancer une capture du trafic au boot de la cam. Voici ce que j'obtiens: No. Time Source Destination Protocol Length Info 6 58.060403 a2imarke_34:5e:76 Broadcast ARP 60 Who has 172.16.80.1? Tell 172.16.80.81 Frame 6: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) Ethernet II, Src: a2imarke_34:5e:76 (00:12:41:34:5e:76), Dst: Broadcast (ff:ff:ff:ff:ff:ff) Address Resolution Protocol (request) No. Time Source Destination Protocol Length Info 7 59.059478 a2imarke_34:5e:76 Broadcast ARP 60 Who has 172.16.80.1? Tell 172.16.80.81 Frame 7: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) Ethernet II, Src: a2imarke_34:5e:76 (00:12:41:34:5e:76), Dst: Broadcast (ff:ff:ff:ff:ff:ff) Address Resolution Protocol (request) No. Time Source Destination Protocol Length Info 8 60.059471 a2imarke_34:5e:76 Broadcast ARP 60 Who has 172.16.80.1? Tell 172.16.80.81 Frame 8: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) Ethernet II, Src: a2imarke_34:5e:76 (00:12:41:34:5e:76), Dst: Broadcast (ff:ff:ff:ff:ff:ff) Address Resolution Protocol (request) No. Time Source Destination Protocol Length Info 18 88.820063 a2imarke_34:5e:76 Broadcast ARP 60 ARP Announcement for 172.16.80.81 Frame 18: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) Ethernet II, Src: a2imarke_34:5e:76 (00:12:41:34:5e:76), Dst: Broadcast (ff:ff:ff:ff:ff:ff) Address Resolution Protocol (ARP Announcement) rien de plus que du trafic ARP. Ce qui explique les entrées au niveau du switch. Par contre aucun trafic DHCP ou BOOTP. Pourtant la cam me ressort l'IP que mon dhcpd est sensé lui attribuer. Il a donc dû stocker ça quelque part dans une NVRAM. Bref, j'en arrive à la conclusion que la stack DHCP de cette cam pue grave du fion, ce qui explique pourquoi dans la doc succincte fournie avec la cam ils spécifient "We do not recommand leaving the IP camera on DHCP" (en config usine elle est en 192.168.1.10/24 statique) Quand je tente de pinger cette saleté de cam, voici ce que j'obtiens en capture: No. Time Source Destination Protocol Length Info 1 0.00 ASUSTekC_c4:19:e3 Broadcast ARP 60 Who has 172.16.80.81? Tell 172.16.80.90 Frame 1: 60 bytes on wire (480 bits),
