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.