Team Leader - Nutanix Technology Champion - Nutanix NTC Storyteller

Julien DUMUR
Infrastructure in a Nutshell

ipmi

IPMI injoignable : le retrouver en IPv6 link-local

Published: 7 septembre 2026
Written by Julien D.
No comments
Categories: Nutanix, Nutanix AHV FR, Réseau, Tech et Lab
Retrouver un IPMI injoignable en IPv6 link-local

Ce week-end, j’ai voulu déplacer l’IPMI de mon node Nutanix de lab sur mon segment d’administration. J’ai changé l’adresse de la carte et le profil de VLAN du port du switch dans la même minute. Le node venait d’être réinitialisé, il n’avait plus de système, donc plus aucun moyen de corriger depuis l’intérieur, et la carte a disparu du réseau.

Ce qui m’a rendu la main tient en une adresse IPv6 link-local et deux commandes, un quart d’heure montre en main. Voici la méthode, sous Windows 11 et sous Rocky Linux.

Le soir où l’IPMI a disparu du réseau

Deux changements dans la même minute m’ont privé de tout moyen de savoir lequel des deux avait cassé quoi. J’ai branché un laptop en direct sur le port IPMI dédié de ce Supermicro SYS-5019D-4C-FN8TP pour reprendre la main.

Sur un node qui tourne, ipmitool en local règle ce genre de bêtise en une commande via l’interface KCS, sans passer par le réseau, mais un serveur fraîchement effacé ferme cette porte. Si vous êtes dans la situation inverse, la carte joignable mais le mot de passe perdu, je vous invite à consulter mon article à ce sujet : mot de passe IPMI perdu sur un noeud Nutanix ou Supermicro.

Pourquoi le link-local répond quand l’IPv4 est muette

Toute interface IPv6 active porte une adresse qui commence par fe80::, construite toute seule à partir de sa MAC et sans DHCP. Une machine dont l’IPv4 est fausse ou absente garde donc une identité joignable sur son segment. L’adresse ff02::1 est le groupe multicast dit all-nodes : un ping vers ce groupe fait répondre tout ce qui vit au bout du câble, et un IPMI alimenté en veille répond même serveur éteint. Le multicast ne traverse pas un routeur, il faut donc être sur le même segment que la carte.

Un détail achève de justifier la méthode, vu plus tard en relisant la configuration de ma carte en firmware 01.74.13 : la ligne « ARP Responses Enabled, Gratuitous ARP Disabled ». L’IPMI ne s’annonce jamais spontanément, donc écouter passivement le segment ne mène nulle part.

Retrouver la carte sur le câble

Le principe est le même sur les deux systèmes : identifier l’interface, envoyer le multicast, lire le cache voisinage.

Sous Windows 11

  • Repérage de la carte et de son index :
Get-NetAdapter

La colonne ifIndex donne le numéro à réutiliser ensuite, l’index 3 chez moi.

Sur un lien direct il n’y a aucun serveur DHCP, et une interface restée en automatique bascule en APIPA sur 169.254.x.x, auquel cas rien ne pinguera jamais, même face à un IPMI en parfait état. Posez une adresse statique :

New-NetIPAddress -InterfaceAlias "Ethernet" -IPAddress 192.168.10.50 -PrefixLength 24
  • Envoi du multicast, avec l’index de l’interface en suffixe de zone :
ping -6 ff02::1%3
  • Lecture des voisins découverts, avec leur adresse MAC :
Get-NetNeighbor -InterfaceIndex 3

Sous Rocky Linux

  • Identification de l’interface :
ip link show
  • Envoi du multicast :
ping6 -c4 ff02::1%ens0
  • Retour de la commande :
PING ff02::1%ens0(ff02::1%ens0) 56 data bytes
64 bytes from fe80:0:0:0:225:90ff:feb8:f313%ens0: icmp_seq=1 ttl=64 time=0.659 ms
64 bytes from fe80:0:0:0:225:90ff:feb8:f313%ens0: icmp_seq=2 ttl=64 time=0.288 ms
  • Association des adresses à leur MAC :
ip -6 neigh show dev ens0

Une nuance fait perdre du temps quand on passe d’un système à l’autre : le suffixe de zone prend un nom d’interface sous Linux et un index numérique sous Windows, et une adresse copiée d’une console à l’autre échoue sans message explicite.

Lire le constructeur directement dans l’adresse

Quand une adresse link-local contient ff:fe en son milieu, elle dérive de la MAC par la méthode EUI-64, et l’opération s’inverse de tête. Retirez les deux octets ff:fe du centre de fe80::225:90ff:feb8:f313, il reste 02:25:90:b8:f3:13, puis inversez le deuxième bit du premier octet : 02 devient 00, soit un OUI Super Micro Computer.

Ouvrir l’interface web en link-local

L’adresse récupérée s’utilise telle quelle dans un navigateur, entre crochets et suivie de son suffixe de zone :

https://[fe80::225:90ff:feb8:f313%3]

Le suffixe est obligatoire, une adresse link-local n’étant unique que sur un segment donné. Si votre navigateur refuse ce format, curl confirmera que le service répond, avec le % échappé en %25 et l’option -g sans laquelle les crochets partent en globbing :

curl -k -g "https://[fe80::225:90ff:feb8:f313%25ens0]/"

Ce que l’IPMI m’a révélé

Une fois l’interface ouverte, la réponse tenait en une ligne de sa page réseau : la carte portait 192.168.10.11, quand je pensais avoir configuré 192.168.10.1. Le profil de VLAN du port n’y était pour rien, et l’adresse que j’avais saisie est celle de la machine qui héberge mon DNS. Reconfiguration sur la bonne adresse, et c’était reparti.

Mes cartes de gestion vivent maintenant dans une plage réservée en bas du segment, avec une exclusion DHCP en face, le node de lab en .1 et celui de production en .2. Et je m’applique une règle simple depuis : un seul changement à la fois, vérifié avant le suivant.

Read More

Mot de passe IPMI perdu sur un nœud Nutanix ou Supermicro : Le guide de récupération

Published: 10 août 2026
Written by Julien D.
1 Comment
Categories: Nutanix, Nutanix AHV FR, Tech et Lab
Récupérer un mot de passe IPMI perdu sur un nœud Nutanix ou Supermicro

Il m’est arrivé une petite mésaventure récemment. Après un changement de mot de passe IPMI sur mon 1-node, impossible de me reconnecter à l’interface de management de mon nœud. Oubli dans la seconde ? Faute de frappe ? Copier coller foireux ? Qu’importe la raison, le verrouillage de l’accès, lui, était bien réel.

Perdre son mot de passe IPMI (ou BMC) fait souvent transpirer. Mais rassurez-vous, l’expérience m’a appris une règle d’or : tant que vous avez encore un accès au système d’exploitation de l’hôte (que ce soit AHV, un Linux standard ou même ESXi), vous pouvez récupérer la main sans avoir besoin de faire un reset matériel.

Toutefois, la situation peut être plus critique qu’il n’y paraît. Pour les experts qui me lisent, vous savez qu’en environnement Nutanix Single-Node, l’IPMI n’est pas juste un confort d’administration : c’est votre seul et unique fail-safe. Sans lui, impossible de monter une ISO Phoenix en Remote Media lors d’un crash AOS majeur ou pour forcer un redémarrage. Perdre l’accès BMC sur un tel nœud devient donc très vite un point de blocage impactant pour votre production et l’accès à la console distante.

Dans ce guide, je vous partage les différentes méthodes pour reprendre le contrôle sur votre noeud en quelques minutes, de la plus douce à celle de la dernière chance.

Méthode 1 : Réinitialisation in-band via ipmitool

Si vous êtes sous Nutanix AHV ou une distribution Linux classique, vous avez de la chance : l’utilitaire ipmitool est généralement présent nativement. L’astuce de cette méthode repose sur le canal matériel KCS (Keyboard Controller Style). En clair, cela permet à l’OS de l’hôte de communiquer directement avec la puce BMC via le bus de la carte mère (LPC/PCIe), sans passer par le réseau de management.

Identifier et écraser le compte Admin

Connectez-vous en root sur votre hôte. Par précaution, on s’assure d’abord que les modules noyaux gérant l’IPMI sont bien chargés :

modprobe ipmi_si
modprobe ipmi_devintf

Ensuite, on va lister les utilisateurs configurés (généralement sur le channel 1) pour repérer l’ID de notre compte administrateur. Dans 99% des cas, le compte par défaut (ADMIN) correspond à l’ID 2.

ipmitool user list 1

Dans mon cas, l’ID correspond bien à 2 :

Résultat de ipmitool user list 1 avec le compte ADMIN en ID 2

Une fois l’ID confirmé, la commande pour forcer un nouveau mot de passe est enfantine :

ipmitool user set password 2 'MonNouveauMdp123!'

Lors de la saisie de la commande précédente, il se peut que le terminal vous renvoie un vilain Invalid data field in request.

Pas de panique, c’est simplement le parseur de politique de sécurité de certains firmwares qui rejette votre demande. Il exige non seulement une complexité minimale (8 caractères, majuscule, minuscule, chiffre), mais peut aussi être capricieux sur le format de la requête.

Pour contourner (ou plutôt satisfaire) ce mécanisme, forcez la longueur d’encodage sur 20 octets en ajoutant simplement 20 à la fin de votre commande :

ipmitool user set password 2 'MonNouveauMdp123!' 20

Votre mot de passe est maintenant écrasé. Vous pouvez tester la connexion à l’interface web.

Méthode 2 : L’utilitaire IPMICFG (La solution pour VMware ESXi)

Si vous êtes sous VMware ESXi, la première méthode risque de vous laisser sur le carreau. Pourquoi ? Parce qu’ipmitool n’y est pas packagé nativement et résoudre les dépendances pour le compiler sur un hyperviseur est une perte de temps que je ne vous recommande pas.

La parade s’appelle IPMICFG. C’est l’outil officiel fourni par Supermicro (téléchargeable sur leur portail avec un compte gratuit). L’immense avantage est qu’il est fourni sous forme de binaires statiques, prêts à l’emploi pour Linux ou Windows.

Une fois l’archive transférée sur votre hôte et décompressée, son utilisation est très simple :

./IPMICFG-Linux.x86_64 -user list
./IPMICFG-Linux.x86_64 -user setpwd 2 MonNouveauMdp123!

Note : adaptez le nom du binaire si vous utilisez la version Windows ou Linux.

Vous pouvez récupérer l’utilitaire ici : https://www.supermicro.com/wdl/utility/IPMICFG/

Cas extrême : Le nœud n’a plus d’OS bootable

Que faire si l’OS ne démarre plus du tout ? C’est souvent là qu’on transpire, pensant que sans accès réseau à l’IPMI ni système d’exploitation fonctionnel, la seule méthode restante est le reset usine.

Rappelez-vous : l’interface KCS est exposée au niveau matériel dès la fin du POST BIOS. Elle est totalement indépendante de l’état de votre stockage.

Il suffit donc de booter le serveur sur une clé USB contenant un Live CD Linux (Ubuntu, Rocky Linux). Une fois sur le bureau éphémère, ouvrez un terminal, installez l’utilitaire s’il n’est pas déjà présent (apt install ipmitool par exemple), et reprenez exactement les commandes de la Méthode 1.

Méthode de dernier recours : Le Factory Reset du BMC

Si pour une raison obscure les méthodes précédentes échouent, il reste l’ultime recours : le reset aux paramètres d’usine.

Avec l’outil de Supermicro, la commande est directe :

./IPMICFG-Linux.x86_64 -fd

Et si vous préférez la méthode ipmitool pure, il faut passer une commande RAW :

ipmitool raw 0x3c 0x40

⚠️ Attention, les conséquences sont lourdes : Toute votre configuration BMC est remise à zéro. Vous perdez l’IP statique (le port repasse en DHCP), la configuration des VLANs, et vos comptes utilisateurs. Le BMC va ensuite redémarrer (comptez bien 2 à 3 minutes). Gros point de vigilance sur les générations récentes de serveurs : il se peut que le mot de passe ne redevienne pas ADMIN/ADMIN. Il bascule sur le mot de passe unique imprimé sur l’étiquette OCP (souvent collée sur le châssis ou la carte mère). Pensez-y si votre serveur est physiquement à l’autre bout du monde !

Mes recommandations

Une fois l’accès récupéré via la méthode 1 ou 2, voici ce que je fais systématiquement pour sécuriser mes arrières :

  1. Le gestionnaire de mots de passe : C’est basique, mais renseignez vos creds immédiatement au lieu de le garder dans le cache du copié-collé.
  2. Le compte de secours : Créez un second compte administrateur.
  3. L’astuce du Slot ID : Ne mettez pas votre compte de secours sur le Slot ID 3. Forcez sa création sur un Slot plus éloigné (comme le 5 ou le 6). Pourquoi ? Parce que certains scripts d’automatisation d’infrastructure ont parfois la fâcheuse tendance à écraser ou modifier en force les premiers Slots (2 et 3) lors du provisionning. En le mettant plus loin, vous le sanctuarisez.

Et vous, ça vous est déjà arrivé de vous enfermer dehors sur l’un de vos nœuds ? Partagez votre pire galère dans les commentaires ci-dessous !

Read More