Opérations de base sur Comware OS (switches HPE FlexFabric)

TL;DR

J’ai récemment eu l’occasion de travailler avec un switch HPE5700. Ce modèle est issu du catalogue H3C et tourne sous Comware OS.

Assez déroutant lorsque l’on a pris l’habitude de la cli Cisco. Ce billet traite de la mise en oeuvre initiale et des opérations de base pour un switch fonctionnant sous Comware OS7.

N’ayant qu’un seul switch, je n’ai malheureusement pas la possibilité de tester les fonctions avancées telles que IRF1.

Caractéristiques physiques du HPE 5700-48

Le 5700 48G (modèle JG894A) est un switch datacenre composé des ports suivants :
– face avant :
– 48 ports fixes GbE base-T,
– 4 ports 10GbE SFP+,
– 2 ports 40GbE QSFP+
– face arrière :
– 1 port GbE base-T pour le management (OOBM),
– 1 port console.

Voici un lien vers le document quickspec HP5700

Basculer entre les modes view/config, sauvegarder la config

On démarre en mode visualisation lors de la première connexion, appelé display mode. Cela correspond au mode show et on ne peut que afficher les paramètres actuels. Il faut exécuter la commande «system-view» pour basculer en mode configuration. Le prompt passe alors du signe \> au signe \#.

hpswitch>system-view
hpswitch#

La sauvegarde de la configuration s’effectuer à l’aide de la commande «save».

hpswitch# save force

Le paramètre «force» évite d’avoir à confirmer l’action et spécifier un nom de fichier.

Configuring remote out of band management

Cette partie est composée de 5 tâches :

  1. Configurer l’IP de l’interface de management,
  2. Définir la passerelle par défaut,
  3. Créer un utilisateur local de niveau administrateur,
  4. Activer un protocole de gestion à distance (ssh de préférence),
  5. Configurer les lignes de connexion vty (Virtual Teletype).

Configuration de l’IP sur l’interface de management

Après avoir basculé en mode system-view, il faut sélectionner l’interface de management puis définir adresse IP et masque de sous-réseau.

interface M-GigabitEthernet0/0/0
ip address 172.30.1.77 24

Ajout de la route par défaut pour l’interface de management

ip route-static 0.0.0.0 0 M-GigabitEthernet 0/0/0 172.30.1.250 permanent

création d’un utilisateur local, affectation du rôle « network-admin » (full feature) & autorisation d’accès via SSH

local-user admin
password simple service-type ssh
authorization-attribute user-role network-admin

Configuration SSH

Tout d’abord, on active le service SSH :

ssh server enable

Puis on génère les clés cryptographiques :

Public-key local create rss

Configuration des 15 premiers vty & autorisation SSH

line vty 0 15
authentication-mode scheme
protocol inbound ssh

Quelques commandes utiles

Configurer un uplink en mode trunk et véhiculer tous les VLANs

Interface GigabitEthernet 1/0/48
port link-type trunk
port trunk permit vlan all

Créer une SVI pour un vlan

interface Vlan-interface
ip address 10.0.0.252 24

Split des interfaces 40GbE en 10GbE

Les interfaces 40GbE peuvent être divisées en 4 interfaces 10GbE. Cela nécessite un redémarrage du switch ainsi qu’un câble pieuvre (break-out cable).

Sélectionner une interface 40GbE et exécuter la commande suivante :

using tengige

Au reboot, les interfaces 10GbE sont présentes. Les 4 interfaces 10GbE sont numérotées à la manière d’une sous-interface (XX:X).

[HPE-5700]display interface brief
…
XGE1/0/53:1 UP 10G(a) F(a) A 1
XGE1/0/53:2 UP 10G(a) F(a) A 1
XGE1/0/53:3 UP 10G(a) F(a) A 1
XGE1/0/53:4 UP 10G(a) F(a) A 1
XGE1/0/54:1 UP 10G(a) F(a) A 1
XGE1/0/54:2 UP 10G(a) F(a) A 1
XGE1/0/54:3 UP 10G(a) F(a) A 1
XGE1/0/54:4 UP 10G(a) F(a) A 1

Configurer un port trunk avec un native vlan

La configuration d’un vlan natif sur un port trunk nécessite de placer le port en mode hybrid (requiert d’abord le mode access).

[HPE-5700-Ten-GigabitEthernet1/0/53:1]port link-type hybrid
Please set the link type of the port to access first.
[HPE-5700-Ten-GigabitEthernet1/0/53:1]port link-type access
[HPE-5700-Ten-GigabitEthernet1/0/53:1]port link-type hybrid

Configuration du native vlan

[HPE-5700-Ten-GigabitEthernet1/0/53:1]port hybrid vlan 500 untagged

Configuration du trunked vlan

[HPE-5700-Ten-GigabitEthernet1/0/53:1]port hybrid vlan 502 tagged

Résumé des commandes nécessaires pour la configuration d’un port Trunk avec un vlan natif

port link-type access
port link-type hybrid
port hybrid vlan 500 untagged
port hybrid vlan 502 tagged

  1. IRF : Intelligent Resilient Framework, la technologie mLAG d’HPE (comparable au vPC Cisco). 
Publié dans CLI Tagués avec : , , , ,

Configurer une interface en GbE sur Nexus 50xx/55xx/56xx

Les switchs Nexus constituent la gamme Datacenter chez Cisco. Ils sont optimisés pour les connexions 10GbE et supérieur, et présentent un bien meilleur prix au port 10GbE par rapport à la gamme Catalyst. Il est cependant parfois nécessaire d’avoir une connexion Gigabit Ethernet, entre autre pour se connecter à l’architecture existant.

Pour cela les modules GLC-T sont nécessaires.
Note : prolabs manufacture des Gbic compatibles, avec un prix intéressant.

L’erreur typique rencontrée est « SFP Validation Failed », malgré un SFP compatible. Afin d’avoir un port fonctionnel, il faut configurer le port avant d’insérer le SFP.

  1. Définir la vitesse du port avant insertion du SFP
conf
int e1/1
speed 1000
  1. Insérer le SFP dans un port compatible 1/10GbE :
  • Sur les Nexus 5010 : ports 1 à 8,
  • Sur les Nexus 5020 : ports 1 à 16,
  • Sur les Nexus 5500/5600 : ports 1 à 32.

Note : sur les 5500/5600, un port configuré en speed auto basculera automatiquement la configuration entre 1GbE et 10GbE.

Références

http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5000/sw/configuration/guide/cli/CLIConfigurationGuide/BasicEthernet.html
A Cisco Nexus 5000 Series switch has a number of fixed 10-Gigabit ports, each equipped with SFP+ interface adapters. The Nexus 5010 switch has 20 fixed ports, the first eight of which are switchable 1-Gigabit/10-Gigabit ports. The Nexus 5020 switch has 40 fixed ports, the first 16 of which are switchable 1-Gigabit/10-Gigabit ports.

http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5500/sw/interfaces/7x/b_5500_Interfaces_Config_Guide_Release_7x/b_5500_Interfaces_Config_Guide_Release_7x_chapter_01.html
The 5596T switch has 48 base board ports and 3 GEM slots. The first 32 ports are 10GBase-T ports the last 16 ports are SFP+ ports. The 10GBase-T ports support a speed of 1-Gigabit, 10-Gigabit, or Auto. The Auto setting automatically negotiates with the link parser to select either 1-Gigabit or 10-Gigabit speed.

http://serverfault.com/questions/339957/how-do-i-get-past-sfp-validation-failed-on-a-sfp-ge-t-transceiver-on-a-nexus-5
https://supportforums.cisco.com/discussion/11510966/nexus-5020-and-glc-t

Publié dans CLI Tagués avec : , , , ,

Crash Test – Que se passe-t-il lorsque vous perdez L1&L2 sur un cluster UCSM?

Nexus-L1L2L1 & L2, c’est quoi?

Les liens L1 et L2 sont des ports physiques dédiés (GbE) sur les platefome UCS Fabric Interconnect, véhiculant le traffic de heartbeat de l’application en cluster UCSM. Autant dire qu’ils sont cruciaux à la survie du cluster!

L’image du post est bien un Nexus, et ce n’est pas une erreur :-). Pour la petite histoire, les Fabric Interconnect (ou FI), sont basés sur une plateforme matérielle Nexus, adaptée pour la situation :

  • Les FI Gen 1 (6100XP) sont basés sur les plateformes matérielles Nexus 5000,
  • Les FI Gen 2 (6200UP) sont basés sur les plateformes matérielles Nexus 5500.

Si vous vous demandiez « à quoi servent les ports L1 & L2 sur mon joli Nexus tout neuf? », vous avez votre réponse : ils ne servent à rien (sur un Nexus). Ils sont présents depuis le début sur les Nexus, car la vision moyen terme prévoyait déjà une déclinaison du boîtier pour servir de base matérielle aux futur Fabric Interconnects.

Il faut y voir une simple rationalisation des chaînes de production : il est plus rentable de laisser ces 4 ports GbE sur l’ensemble des boites plutôt que de gérer l’exception.

Et oui, la société à la genèse de la gamme Nexus (Nuova Systems, qui a été racheté par Cisco en 2008) pensait aigle UCS dès le départ. Si l’on se penche un peu sur le parcours des fondateurs de Nuova, le puzzle devient tout de suite plus clair. Ce sont trois anciens cerveaux de chez Cisco, Mario Mazzola, Prem Jaim & Luca Cafiero, que j’aime appeler les trois mousquetaires 🙂 (même si le trio est à majorité italienne), et ils n’en sont pas à leur coup d’essai. Mais ceci est une autre histoire – à destination d’un autre billet pourquoi pas.

Pour revenir aux ports L1 & L2, tout en restant dans l’analogie avec les plateformes Nexus, les liens L1 & L2 pourrait être assimilés aux liens VPC Peer-Links, à quelques détails près. Dit comme ça, je suis certains que ça parle à tout le monde 🙂

Note : les connexions des ports L1 & L2 sur chaque FI se fait de la manière suivante :

  • FI-A L1 <–> FI-B L1,
  • FI-A L2 <–> FI-B L2.

Autre détail (de taille), pas de switch sur le chemin des connexions L1 & L2!!! Ces ports sont configurés en bonding et attendent à l’autre bout de la connexion : un autre Fabric Interconnect. Ne pensez pas à configurer du port-channel côté switch, placer les bons vlans, etc : c’est une configuration explicitement hors support.

Le traffic de heartbeat

UCSM est le logiciel de gestion de la plateforme UCS. Il est embarqué au sein de chaque Fabric Interconnect et fonctionne en mode Actif/Passif. La motivation et la pertinence de ce choix, plutôt que d’opter pour une application à installer ou exécuter au sein d’une VM, pourrait alimenter tout une tribu de troll.

– Ici on aime les trolls mais ils seront nourris une autre fois dans un autre billet (encore!) –

Comme toute application en cluster, un lien de signalisation est nécessaire afin de pouvoir maintenir une bonne connaissance de l’état de santé de chaque membre : cela se fait généralement via un lien de heartbeat redondé, autrement dit un bus de communication.

Nous sommes donc ici en présence d’un cluster à deux membres, et ce n’est pas un détail.

Perte d’un membre et Split-Brain

Le cluster surveille l’état de santé de chaque membre via le lien de heartbeat, et bascule les services sur un membre réputé sein en cas de panne. Sans entrer dans les détails et transformer cet article en un essai sur les clusters (c’est bien prétentieux :-)), un membre est réputé sein si le quorum (voir la définition stricte, et ne pas faire d’amalgame avec du jargon Microsoft) est atteint au sein des membres. Pour un cluster à deux membres, c’est la parole d’un bandit contre un autre … Il faut donc faire recours à un arbitre (appelé suivant les technologies : « Tie-Breaker », « Failover Monitor », etc …), afin d’éviter le phénomène de Split-brain.  Dans un cluster UCSM, c’est la passerelle par défaut qui fait office d’arbitre lorsqu’un membre n’arrive pas à joindre l’autre.

Note : le cluster UCSM effectue un test supplémentaire, visant à vérifier le lien entre le FI et le/les châssis. Il s’appuie pour cela sur la SEEPROM (Serial EEPROM) : espace de stockage en mémoire non-volatile, accessible par chaque FI. L’article suivant chez UCSGuru explique un peu plus en détail les différents tests menés, ainsi que le cas particulier de serveurs C-Series (format rack), qui ne disposent pas de SEEPROM : HA with UCSM Integrated Rack Mounts.

Que se passe-t-il lorsque l’on perd les liens L1&L2 sur un cluster UCSM?

Toute cette introduction pour arriver à la question initiale. Quel est l’effet concret constaté, d’un point de vue opérateur/administrateur?

Lorsque un des deux liens n’est plus disponible, une alerte de type « majeur » est remontée dans UCSM pour chaque FI : « HA Cluster interconnect Link Failure »

  • Erreur visible « immédiatement »,
  • Pas d’impact sur le data path.

Lorsque les deux liens ne sont plus disponibles (L1 & L2), après une période de timeout (En minutes) :

  • Une nouvelle erreur de type « Critique » est levée : « HAClusterInterconnectTotallinkfailure »,
    • Le FI subordinate est déclaré « injoignable »,
    • Toutes la partie B est « shut » (en admettant que c’était la partie passive (subordinate) du cluster UCSM) DATA PATH compris :
      • FEX,
      • Uplinks LAN & SAN.

Attention donc à vos liens L1 & L2, il faut les choyer et assurer la présence d’au-moins un lien sur deux, sinon effets surprise-party garanti!

Je n’ai malheureusement pas connaissance de la durée exacte du timeout avant coupure complète de la partie « passive ». L’ordre de grandeur est en minutes, j’essayerai de reproduire le test à l’occasion, équipé d’un super chronographe mécanique 😀

Toujours pour rester dans l’analogie avec les Nexus et le mécanisme VPC, c’est un comportement similaire qui est observé lorsque l’on perd le sacro-saint VPC Peer-Link : le secondary est sacrifié sur l’autel du split-brain.

Retour à la normale

Lorsqu’au moins un des liens est de nouveau présent :

  • Resync du FI subordinate sur le primary,
  • Réactivation des liens,
  • Rétablissement du cluster UCSM.

Notes et recommandations sur L1&L2

  • Les connexions L1-L1 et L2-L2 doivent être en DIRECT, pas de switchs sur le chemin,
  • En cas de migration/déménagement, on peut être amené à fonctionner avec seulement L1, mais essayez de garder cette période aussi courte que possible et rendez lui au plus vite son copain L2,
  • Média Ethernet : les limitations usuelles s’appliquent, ne dépassez pas les 100m!
Publié dans Design, Infrastructure Tagués avec : , ,