Comment la bande latérale IPMI partage-t-elle le port Ethernet avec l'hôte?

Nous avons un certain nombre de machines Supermicro avec des fonctionnalités IPMI / BMC. Certaines de ces machines utilisent un BMC intégré, tandis que d'autres utilisent une carte d'extension .

Nous envisageons d'utiliser la bande latérale en raison de la réduction des coûts et des exigences de câblage. Cependant, certains détails de la bande latérale n'ont pas vraiment de sens.

La bande latérale nécessite un câble Ethernet qui est branché sur un port Ethernet de la carte mère. Ce port réseau est ensuite partagé entre le système IPMI et le système d'exploitation. D'après ce que j'ai lu dans ce manuel de Supermicro , "Utilisez la même adresse MAC que vous utilisez pour LAN1 pour la carte SIMSO IPMI". Cependant, l'IPMI doit avoir une adresse IP différente de celle du système d'exploitation.

Comment est-il possible d'avoir deux appareils (le système d'exploitation et l'IPMI) qui peuvent écouter et transmettre sur ce même port réseau physique? Lorsqu'un paquet arrive à l'interface, comment le système détermine-t-il si ce paquet est destiné au système d'exploitation ou au système IPMI?

Ces paquets sont-ils gérés par le CPU, en utilisant des interruptions du CPU? Les paquets vers l'interface IPMI peuvent-ils être visualisés par le système d'exploitation?

Je gère de nombreux serveurs SuperMicro à l'aide de l'IPMI intégré. J'ai une relation d'amour / haine avec l'Ethernet partagé (aka bande latérale). En général, la façon dont ces choses fonctionnent est que LAN1 semble avoir 2 adresses MAC (différentes) - l'une pour l'interface IPMI, l'autre pour votre NIC Broadcom standard. Le trafic vers l'interface IPMI (couche 2, basée sur l'adresse MAC) est intercepté comme par magie en dessous du niveau du système d'exploitation et n'est jamais vu par le système d'exploitation en cours d'exécution.

Vous avez déjà trouvé un seul bon point pour eux: moins de câblage. Maintenant, permettez-moi de couvrir certains des inconvénients:

• Il est particulièrement difficile de partitionner l'interface IPMI sur un sous-réseau séparé de manière sécurisée. Étant donné que tout le trafic passe par le même câble, vous devez (presque) toujours avoir l'interface IPMI et l'interface LAN1 sur le même sous-réseau IP. Sur les dernières cartes mères, les cartes IPMI prennent désormais en charge l'attribution d'un VLAN au NIC IPMI, de sorte que vous pouvez obtenir un semblant de séparation - mais le système d'exploitation sous-jacent pourrait toujours flairer le trafic pour ce VLAN. Les contrôleurs BMC plus anciens ne permettent pas du tout de changer le VLAN, bien que des outils comme ipmitool ou ipmicfg vous permettent ostensiblement de le changer, cela ne fonctionne tout simplement pas.
• Vous centralisez vos points de défaillance sur le système. Faire la configuration sur un commutateur et réussir à vous couper en quelque sorte? Félicitations, vous avez maintenant coupé la connexion réseau principale à votre serveur ET la sauvegarde via IPMI. Échec du matériel NIC? Félicitations, même problème.
• Les premiers SuperMicro IPMI BMC étaient connus pour faire des choses loufoques avec l'interface réseau. La question de savoir si utiliser le port IPMI intégré ou dédié a souvent été déterminée à la mise sous tension (pas au redémarrage) et ne basculerait pas à partir de là. Si vous avez eu une panne de courant et que votre commutateur n'a pas fourni suffisamment de courant, vous pourriez vous retrouver avec l'IPMI ne fonctionnant pas car il a détecté automatiquement le mauvais paramètre.
• J'ai personnellement eu beaucoup de problèmes de connectivité étranges et inexplicables pour que l'IPMI de la bande latérale fonctionne de manière fiable. Parfois, je ne pouvais tout simplement pas cingler l'adresse IP de l'interface pendant quelques minutes. Parfois, je recevais une tempête de paquets sur le VLAN attribué, mais le trafic semblait être abandonné.

Bien que cela n'ait rien à voir avec la bande latérale vs dédiée, je noterai également que les outils pour accéder aux systèmes hôtes sont très mal écrits. Les cartes IPMI plus anciennes ne prennent en charge rien d'autre que l'authentification locale, ce qui rend la rotation des mots de passe très difficile. Si vous utilisez la fonctionnalité KVM sur IP, vous êtes bloqué en utilisant une applet Java expirée de manière incorrecte ou une application de bureau Java étrange qui ne fonctionne que sur Windows et nécessite une élévation UAC pour s'exécuter. J'ai trouvé l'entrée de clavier au mieux inégale, obtenant parfois des "touches bloquées" de sorte qu'il est impossible de taper un mot de passe pour se connecter sans essayer 10 fois.

J'ai finalement réussi à faire fonctionner plus de 40 systèmes avec cet arrangement. J'ai surtout des systèmes plus récents, je peux VLAN les interfaces IPMI sur un sous-réseau séparé, et j'utilise principalement la console série via ipmitool qui fonctionne très bien. Pour la prochaine génération de serveurs, je regarde la technologie AMT d'Intel avec prise en charge KVM ; comme cela le fait dans l'espace serveur, je peux voir remplacer IPMI par cela.

Je n'ai jamais utilisé ces cartes particulières auparavant, celles que j'ai utilisées ont un MAC différent pour le bureau IPMI ou le port est dédié au trafic IPMI uniquement. Il est possible que IPMI partage la carte réseau, y compris le MAC.

IPMI aura une IP différente de l'OS, donc les paquets seront dirigés correctement en fonction de cela. Le trafic IPMI n'atteint jamais le CPU, tout est géré dans les circuits intégrés de gestion de la bande latérale.

Je voulais ajouter aux conseils généraux que l'utilisation de la bande latérale signifie que vous ne pouvez pas parler du serveur au BMC. Le trafic semble filtré. J'ai essayé ceci sur le kit IBM / Dell / HP.

Je sauvegarderai la dernière puce de natacados dans sa réponse initiale, vos sessions IPMI expireront au hasard (j'utilise IPMIView de supermicro pour regarder la console sur mes boîtiers). Des choses comme les mises à jour du firmware et les motocyclettes semblent échouer de manière inexplicable et aléatoire.

Grande réponse natacado, incroyablement approfondie.