Reprise du message précédent :

 
il y a un plugin helm qui permet de déployer dans k8s avec terraform

C'est le plan en fait.

TF pour l'infra, Ansible tower pour la config.
Et oui j'ai eu un training de 4j sur TF j'ai eu un gros coup de coeur et déclic. J'ai vu la lumière

Et pareil pour Ansible pour la conf

Ouais je m'émerveille encore de choses que certains maitrisent depuis 10 piges et alors ?

Je comprends mieux comment les collègues qui nous ont rejoint pour faire avancer la partie IaC/DevOps et qui geraient l'infra dans une institution euro ont pu tripler le nombre de vm en 5 ans (on parle du passage de plusieurs milliers à dizaines de milliers de VM, avec des centaines de creation/decomm par jour)

Et ensuite, tu pousses ça avec des pipelines et via des merge sur tes branches du repo git, et c'est parfait.

 
Et dire que chez nous on fait nos installes via les fichiers anaconda, et même la conf avec  

C'est toujours ghost la ref pour les blogs ? https://ghost.org/

tin ça a changé ghost

Nan c'est WordPress

Vade rétro

Mais non ça c'est un antispam

Salut,

J'aurai besoin d'un petit retex si quelqu'un a cela en mémoire.

Est-ce que l'un de vous a mis en place un service webproxy pour un client/sa société et peut-il me dire les ressources allouées comparé aux nombres d'utilisateurs ?

J'ai fait un petit PoC des familles sans filtre ni webcache (ces deux fonctionnalités n'étant pas prévues), mais je manque de ressources pour simuler une montée en charge suffisamment représentative.

Merci

tu veux du déchiffrement TLS ? ça va probablement avoir une importance en terme de ressources utilisées.

Non pas besoin, le but étant d'avoir un simple intermédiaire qui re-balance les requêtes HTTP/HTTPS vers le WAN y appliquer de traitement particulier.

J'avais pensé à un VPN au début mais ça ne correspond pas exactement au besoin. Un service proxy me parait plus léger et scalable.

J'essaie de simuler la chose avec Jmeter.

Vous n'avez pas de systèmes qui refusent vos clés elliptiques ? (enfin des systèmes qui feraient pas déjà chier avec des vieux ciphers)

Nope

ok
 
comment vous gérez vos clés ?  
vous en faite une par.. ?

On parle de ssh ? Une clé privée ne devrait jamais quitter le device sur laquelle elle a été générée

et bah moi je donne ma clé publique à qui veut

Precisé pour le pénible du fond

 
Yes on essaye.    j’ai l’impression que ça s’arrange pas avec les années selon les types de boites (startup). Et vous ?
 
Officiellement : ssh clos. Le useradmin doit utiliser un serveur pour sortir son code/script.  
Une clef user avec passphrase dans le vscode pour remote le serveur. Ce serveur peut envoyer du code/du script sur du repos azure. On a aussi un bashrc commun pour les remotes et du su pour les pmad du matos reseaux avec ldap.
Sauvegarde des log et check en sup.
Le tout est git chaque soir.  
 
Officieusement : le dev/admin passe par un token en https car ca l’emmerde de rebondir sur le serveur intermédiaire.  

Salut, j'ai une question concernant la rapidité d'exécution des changements de conf des switch.
 
J'ai cas d'application assez particulier car c'est pas du réseau "classique" mais on utilise de l'Ethernet et IP dans une application spécifique. Le challenge c'est qu'on utiliserait le switch avec une configuration "statique" qui changerait toutes les x ms (à la manière d'un crosspoint pour ceux qui connaissent).
De manière générale les switch sont configurés via les CLI et les conf n'ont pas l'air de changer très souvent, donc je sais pas si parmi vous certains ont des cas d'utilisation où les conf de switch vont changer toutes les x ms via un fichier de conf updaté régulièrement par exemple et non pas via l'utilisation du CLI ?
Du genre vous changez les VLAN pour suivre un trafic multicast dynamique ou des truc du genre.

A la milliseconde ? En ssh ? Alors que ni le temps d'envoie de la commande ni le temps d'application de la conf ne sont predictibles ou stables à priori ?

Non pas en SSH, via un CPU de contrôle qui est connecté en PCIe au switch.
Pour simplifier, imagine que tu as des fichiers de conf préparés que tu envoie tous les 20 ms, est-ce qu'il faut 0.5ms, 1ms, 10ms, 20+ms au switch pour changer sa conf. C'est compliqué à trouver comme info. On va recevoir des switch d'ici quelques semaines pour tester, mais si certains ont déjà expérimenté, ça permet de réfléchir à un plan B.

Initialement on utilise un crosspoint switch, un switch analogique mais on souhaite passer à l'IP en cherchant à reproduire le fonctionnement. Mais peut-être que le fonctionnement "exact" n'est pas possible et qu'il faut trouver un moyen plus élégant via les techno offerte par l'Ethernet et l'IP.

Après dans des domaine de calcul distribué, potentiellement y a pas mal de changement de routage et assez rapide, mais je ne connais pas en détails le domaine.

Bah... Ça dépend du Switch, et c'est même pas dit que ce soit déterministe.

C'est pas la question (pour le moment). Juste est-ce dans cet ordre de timing ça semble réaliste voire si y a des personnes ici qui ont déjà vu ce type d'utilisation d'un switch où on peut changer une bonne partie de la conf dans des intervalles très courts.  

Peut être les switchs whitebox qui supportent la programmation P4.

Certains switchs ont une API REST de configuration , ça sera probablement plus performant qu'en CLI .
C'est le cas par exemple sur les juniper

 
Les protocoles de routage habituels savent pousser des changements dans le dataplane en quelques dizaines de ms. Et ce délai comprend le recalcul de la RIB (SPF ou autre) et le poussage du nouvel état sur la linecard (vu que dans un use case de réseau classique les deux vont ensemble), donc si tu es intéressé juste par le second si ça se trouve c'est encore beaucoup plus rapide mais je n'ai pas les chiffres. Ça dépend peut-être aussi de la taille des changements que tu veux pousser, y'a peut-être un nombre ou volume différent des appels API vers la linecard qui vont avoir une influence sur la durée de l'opération je sais pas.
 
Mais je n'ai pas très bien compris si tu parles juste d'une linecard ou d'un switch ethernet/IP entier (avec un control plane et tout).

On a va recevoir des switch 10G sur lesquels on va faire tourner DentOS et SONiC et peut-être "juste" un Linux avec switchdev + soft réseaux de base.
SONiC est fait pour les gros switch 100G+ vu que c'est développé par Microsoft pour les DC Azure. Grossièrement l'archi c'est une database qui est poussée vers le hardware (via bus PCIe). Tout ça est dans le userspace, potentiellement un peu plus lent. DentOS est basé sur switchdev qui est dans le kernel space. Un des aspect que l'on testera c'est la latence de transmission globale à partir du moment où on pousse la conf depuis l'OS et l'effet sur le réseau.

En terme de volume le produit final n'a en gros qu'un switch dans la plupart des cas. On peut voir ça comme un minidatacenter de calcul distribué : pas mal de devices connectés mais les liaisons vont changer toutes les 20 ms mais pendant ces 20 ms le routage est statique. Perso je vois l'archi réseau faite à base de VLAN que l'on change toutes les 20ms, ça laisse jusqu'à 4K chemins possibles, couplé à du multicast c'est amplement suffisant dans un premier temps et derrière avec des ACL on peut tirer sur la corde je pense. On ne souhaite pas utiliser, pour le moment, de protocole de routage car on maitrise le réseau et on préfère claquer la conf nous-même, surtout qu'on a qu'un switch et dans de très rare cas 2 voire 3 switch mais on en est pas encore là.

Mais grossièrement je dirais qu'on viendrait refaire une conf d'une 100aine de VLAN + multicast toutes les 20ms. Mais je dois discuter avec le soft pour savoir si on peut pas gratter du temps pour la préparation de la conf, genre on a un UI où on vient faire des réglage, ça prépare une conf et ensuite on pousse, mais le temps de convertir les actions UI en fichier de conf, on a probablement le droit à plusieurs centaines de ms, en revanche le push et la mise en application de la conf (au niveau du switch) doit être très rapide, mais ça je peux demander des infos aux fabricants.

Les switch qu'on va avoir c'est du white box avec un CPU sur lequel tourne le nOS connecté au switch HW (un Marvell et un Broadcom pour pas faire de jaloux)

J'ai beau relire dans tous les sens, j'arrive pas à comprendre le besoin ... et malheureusement, en général, quand il y a pas de besoin, il y a pas de solution ...

J'ai rien compris   sauf qu'il faut update la conf du switch toutes les 10ms
c'est quoi votre business ? pourquoi vous faites ça ?
 
 
autre sujet:
Je veux identifier tout les flux réseau qui transite par un serveur linux.
c'est un openvpn dont l'accès aux LANs une fois authentifié est openbar (que tu sois Regine de la compta ou Adminsys).
 
avez-vous des idées ?
j'ai pensé a ntop mais il me semble qui ne fait que un échantillonnage ? donc je pourrais louper des flux.
un bête log iptables sinon ?
 
le but final c'est de recréer les règles de firewalling à partir du traffic existant.
osef du contenu des paquets.

la réponse générale à ce besoin général est pmacct  

Imagine une sorte de chassis avec beaucoup de processeurs (FPGA en l'occurence), certains fournissent des données, d'autres les traitent et les derniers rendent les données lisibles. Sur nos produits précédents ils sont reliés via un protocole maison et un switch "analogique" qui fait que les FPGA sont reliés en point à point, ces liaisons point à point changent toutes les 10-20ms
Là on souhaite passer sur de l'Ethernet / IP pour relier tout le monde ensemble et donc utiliser un switch Ethernet. La grosse interrogation est de savoir si un switch est capable de voir sa configuration changer toutes les 10/20ms pour refléter un routage qui change entre les différents FPGA et de savoir combien de temps (grosso merdo) le switch met pour appliquer une nouvelle conf.

Tcpdump avec une capture uniquement des IPs et des ports ?

Je comprends tjr pas perso. Tu fous de l'Ethernet ok donc tt le monde peut communiquer ensemble, pk vouloir continuer des pseudos liaisons P2P ?

J'aimerais bien savoir comment arp va kiffer les liaisons L2 qui changent toutes les 20ms

 
ouais je suis en train de partir là dessus du coup.
au moins c'est connu et vite en place

T'as pas besoin d'ARP quand tu sais que t'es seul en point à point sur la ligne, tu balances le paquet et il arrivera à l'autre bout  
 
Je plussoie la question de je@nb en revanche, pourquoi reconfigurer en permanence façon "communication en mode circuit" à l'ancienne, alors que justement le switch permet de faire de la communication moderne "commutation de paquets" ? C'est fini le X.25, il faut parfois penser différemment pour architecturer correctement  
Lien trunk avec X vlans qui représentent tes liaisons P2P si tu veux quand même isoler le domaine de broadcast, ou bien tous tes CPUs sur un seul vlan commun, chaque CPU son adresse MAC, en avant la musique

Moi je veux connaître le projet pour bien comprendre

 
C'est pas du P2P stricto census, y a du multicast, donc on va tester différentes possibilités, soit du multicast basique de chez basique, soit un truc un peu plus évolué avec des VLAN en plus, etc.  
 
Ensuite je rentre pas dans les détails pour des questions de confidentialité, mais c'est pas des pools de FPGA "génériques", on assigne des chemins particuliers entre ceux qui fournissent, ceux qui traitent et ceux qui recoivent.
Un FPGA qui fournit les données, faut imaginer qu'il y a 4-5 flux de données (chacun défini avec une IP ou une MAC, ça dépendra de si on souhaite travailler en L2 ou L3) qui saturent la BP du lien physique, ces 4-5 flux vont pas forcément sur les même FPGA, d'où le switch (au lieu d'avoir, par exemple, 400 liens P2P entre un switch analogique et les FPGA, on a genre 48 ports Ethernet) pour router chaque flux vers le bon FPGA.
 
On ne refait pas toute la config en permanence, car le système tourne avec un tick de 10-20ms, mais quand on applique la conf, il faudrait que ça dure autour de 1 à 2 ms max. Et le pire cas, si y a un script ou autre, c'est que la conf change (pas forcément en entier) toutes les 10-20ms.
 
Je cherche à glaner quelques infos car faire des mesures avec le network OS et tout ça va mettre un peu de temps et mes recherches ne donnent rien, j'ai peut-être pas les bons mots clés.

Ton besoin de multicast est motivé par quoi ? On dirait un problème XY.  
Si tu as juste besoin d'envoyer des flux de certaines machines vers d'autres machines je ne vois même pas de besoin de VLAN ou d'IP, de l'ethernet tout ce qu'il y a de plus classique c'est exactement à ça que ça sert.