Reprise du message précédent :
Arf ! Ca passe en effet, la procédure d'installation via les lignes de commandes PowerShell.  
Garanti : ça ne passait pas avant. La simple commande Connect-VIServer me donnait une erreur. Et là, avec les modules dans le chemin (qui n'a pas bougé pourtant) je suis en train d'importer le .OVH et donc la VM sur l'ESX
J'espère que ça va aller jusqu'au bout mais y a pas de raison que ça bloque.  
 
Merci vraiment de vos retours. Sans exagérer, y a eu des ressources de ma cogip qui étaient dessus et personne n'a réussi. Jusqu'à maintenant et vos conseils
Chouette. Je suis content aujourd'hui  

 
j'avais fait ça aussi mais ça ne passait pas. Sais plus quelle erreur j'avais. Je te dirai quand j'aurai à nouveau la main

C'est une LU qu'un cable réseau de brassage ne doit pas faire moins de 50cm car en dessous c'est pas bon ?

On va déménager suite a une grosse reduction d'effectif (200>35)  donc je me retrouve très bien doté en switchs. L'idée est donc de faire un cablage propre from scratch et de faire une prise réseau en bureau = une prise sur le switch.

Qu'on pourra activer à distance.

Donc en somme deux bandeaux de 24p auront droit a leur switch.
Donc cablage de brassage minimal à prévoir et je comptais mettre une multitude de petits cables de brassage et m'éviter d'acheter des patchbox vu la faible distance a couvrir

C'est pas normalement toujours comme ça ?  

Ou alors tu as des centaines de doubleur RJ45 ?  

ou alors tu brasses pas tout

Je sais pas si c'est mieux ici ou sur AVFFUO.
J'envisage de ne plus avoir ma vieille boîte mail @free.fr qui marche mais en qui je n'ai pas/plus trop confiance.

Par quoi remplacer ? Gmail ou alors un nom de domaine avec quelques boîtes chez un vendeur ? (avec l'avantage de pouvoir se créer des boîtes séparées pour les comptes poubelles ?)

Voila
J'ai vu qu'une boite qui avait une prise réseau = une prise sur le switch c'est parce que tout était géré a distance...
Donc plus rentable de payer un ou deux switch en plus que faire venir 30 fois un gars brasser une prise.
En local tu as 200 prises pour 2x48 sur le switch et au besoin tu passeras à 3x48

 
Ça marche bien même en dessous de 50cm et les normes de l'interdisent pas, pour autant que je sache.

 
ou une armée de petits switches 5 ports un peu partout sur les bureaux pour "économiser" des prises sur le vrai switch

+1
Ils sont souvent plus chiant a placer parce que assez rigides, mais si tu as pile la bonne longueur.

Effectivement... Et on parlera surtout pas du vieux hub dans le lot...  
(Vécu mais ça commence heureusement à dater)

J'en avais dans mon ancienne boite. Avec de la prod en 3x8.
Un petit malin a fait une boucle et avait tout fais planter.
On avait enfin eu le budget pour virer cela, tirer des prises et ajouter un switch.
 
Pourtant il n'y avait meme pas 10 de ces mini switch en service sur le site...

Le STP coûtait trop cher à activer ?

Encore faut-il savoir que ça existe  

 
 
et à la compta ils connaissent pas excel, non plus ?

Je t'avoue que j'ai pas compris que ca ait autant foutu la merde ...
Après c'est pas bibi qui programme les switch

Déjà vu encore une fois  

Mais pour reprendre ton analogie, la compta connait Excel. Mais elle va faire du =A1+C4+....!!! La fonction SOMME ? C'est quoi ça  

pour ca il faut du niveau 2.
 

qui a renouvelé tous les switchs et n'a meme pas pensé au niveau 2 + POE c'est bibi ...

des switches pas niveau 2 ?  

Switch 4.0, disruptifs mon bon monsieur.

ah oui je vois, ils sont dans le Cloud ClickOps nouvelle génération.

Sûrement dans la même équipe qui nous a demandé de pentester une api sans endpoint.

La mise à jour des NS chez OVH c'est toujours la foire on dirait.
J'ai du m'y reprendre à plusieurs fois, et ce n'est que ce soir, que mon ultime tentative est finalement passée.

Heureusement que c'est pour mon lab perso, j'imagine comment tu dois serrer les fesses lors d'une migration, même si t'as prévu le coup de l'autre côté, tu es pas à l'abri du couille ovhesque  

respecte toi

Cay bon je suis chez cloudflare maintenant  

Juniper EX4200 / 4300 c'est pas du netgear /tplink etc...

Euh OK mais je vois pas bien le rapport

Vraiment ?

Vous entendez quoi par niveau 2 en fait ?

Le rapport c'est qu'il ne doit pas savoir configurer un switch juniper.  

 
Pendant ce temps je me coltine un parc en en iOS 15. Monde injuste  

 
une api sans endpoint interessant....

Comme dis plus haut c'est pas bibi qui le fait
 
Mais clairement c'est a fuir ...
On en a briqué deux lors d'une maintenance élec... Tu lances le shutdown l'admin te dis qu'il ne voit plus rien en trame et te dit que c'est bon, on debranche et ben non en fait après 20min c'était pas suffisant....
Ils avaient voulu upgradé les firmware par stack ca prenait 3h par grappe.
 
QUand je suis partit de cette boite il testait des meraki  
 
Tu peux pas stacker des 4200 avec des 4300 mais c'est possible sur la gamme au dessus

Stack=caca, la preuve une fois de plus    
 
Meraki c'est bien a condition d'être neuneu et d'avoir beaucoup d'argent, si ces conditions ne sont pas remplies il y a un risque de déconvenue  

La partie pognon n'était pas un soucis dans mon ex cogip.
Après je pense que sur des réglages très précis je doute que tu les trouves via l'interface web...
 

pourquoi le stack=caca ?

ça ajoute de la complexité pour pas grand chose, complexité qui se paye quand tu veux faire une MAJ firmware, ajouter/supprimer un switch, que tu as une perte de liens malencontreuse ou un bug, bref ça ajoute des modes de panne. Et je ne parle même pas de la modélisation plus compliquée quand on veut avoir une CMDB sérieuse, ni de ce que ça implique quand on veut faire de l'automatisation.
Et ça n'apporte pas grand chose en contrepartie : dans un scénario campus, STP suffit largement pour gérer la redondance des liens, et dans un scénario DC, une stack doit être considérée comme un SPOF (car control plane partagé) donc ce n'est pas un moyen d'apporter de la résilience.

 
intéressant    mais si une stack est considéré comme un spof concrètement comment tu géres la redondance des access reseaux des serveurs connectés dessus ?  

Avec deux routing engine ça fait largement l'affaire pour 99% des gens qui veulent un PCA.

Si tu es bloqué dans l'ancien monde et que tu es contraint de bricoler avec LACP :

- MC-LAG : les deux switches partagent l'état des bundles LACP qu'ils gèrent l'un avec l'autre. Le partage du control plane est limité au strict nécessaire pour faire fonctionner LACP en mode distribué, pour tout le reste les deux switches sont indépendants. Le protocole utilisé est souvent propriétaire même s'il existe un standard ISO (pas implémenté par beaucoup de constructeurs)
- EVPN ESI : fournit la même chose fonctionnellement (bundles LACP partagés sur 2 switches) mais est plus complexe à mettre en place. La complexité supplémentaire est dûe au fait qu'ESI n'est qu'un petit composant d'EVPN, ce dernier servant à beaucoup plus de choses que juste partager des bundles LACP (là ou au contraire MC-LAG sert uniquement à ça)

Si tu es dans une cogip moderne :

- hosts en L3 : c'est IP qui fait le boulot (au lieu d'ethernet, qui n'avait jamais été conçu pour ça), on utilise les mécanismes de résilience habituels d'IP (multihoming, protocoles de routage dynamique). Concrètement chaque carte réseau a son adresse IP et le système/les VM peuvent également avoir leur IP, quand un lien casse c'est détecté par le protocole de routage et les tables de routage sont adaptées en conséquence
- redondance au niveau applicatif : si un service peut fonctionner en mode distribué sur N serveurs, on peut perdre un serveur ou le switch auquel il est rattaché sans que ce soit trop grave et on n'a donc plus de contrainte aussi strictes sur la partie raccordement des serveurs au réseau.

Encore une faille Intel
https://www.intel.com/content/www/u [...] 00828.html