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

23

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?

Stefan Lasiewski
la source

Réponses:

39

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.

natacado
la source
Merci pour l'explication très détaillée. Avez-vous plus d'informations sur la façon dont le trafic "est magiquement intercepté 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"? Nous essayons de comprendre comment cela fonctionne.
Stefan Lasiewski
Un simple pont matériel fera l'affaire.
Antoine Benkemoun
bonne réponse et oui le trafic est ponté
Jim B
2
Stephan - Antoine et Jim l'ont expliqué dans les commentaires - c'est probablement un pont matériel. Considérez-le comme un minuscule commutateur implémenté dans du silicium, connectant l'interface physique NIC à 2 NIC virtuels - un pour IPMI, un pour l'ordinateur principal.
natacado
Merci pour cette explication. C'est exactement comme ça que je pensais que cela fonctionnerait, mais quand j'en discute avec d'autres personnes (administrateurs réseau, administrateurs système), je reçois beaucoup de désaccords.
Stefan Lasiewski
4

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.

Chris S
la source
Je vois. Certaines cartes IPMI sur certains systèmes "partageront l'adresse MAC" (on dirait que Supermicro et Dell le font), tandis que d'autres utilisent des adresses MAC différentes (IBM le fait).
Stefan Lasiewski
3
Sur mes serveurs Dell, l'interface IPMI a un MAC différent même s'il s'agit du même port réseau physique.
sciurus
2

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.

Ed Sykes
la source
d'élaborer sur cela, car cela m'a aussi frappé. ESXI et aucune machine virtuelle ne peuvent accéder au contrôleur BMC (mais les hôtes externes le peuvent), POURQUOI? Parce que le trafic sortant sur le port NSCI (IPMI partagé) devrait frapper un commutateur et rebondir sur le même port. Les commutateurs L2 typiques d'AFAIK ne le font pas.
kevinf
1

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.

Ben Lutgens
la source
1
Assurez-vous que votre firmware IPMI est à jour! S'il existe une déconnexion suffisamment importante entre la version du micrologiciel IPMI et la version du logiciel IPMIView, vous obtiendrez une "erreur de connexion" générique et cryptique lorsque vous tentez de lancer une session KVM! La mise à jour du dernier firmware IPMI (cela peut être fait à partir du menu principal de l'utilitaire IPMIView sous Fichier) l'a corrigé. : p
Jeff Atwood