Dépannage de l'installation du matériel et du pilote logiciel Nexus SmartNIC

Introduction

Ce document décrit les étapes utilisées pour dépanner l'installation de pilotes matériels et logiciels pour les cartes d'interface réseau à faible latence Nexus SmartNIC (anciennement Exablaze ExaNIC).

Conditions préalables

Exigences

Cisco vous recommande de comprendre la procédure d'installation matérielle des cartes d'interface réseau à faible latence de la gamme Nexus SmartNIC. Cisco vous recommande également de posséder une compréhension de base de l'interface de ligne de commande Linux.

Composants utilisés

Les informations de ce document ont été créées à partir de périphériques dans un environnement de travaux pratiques spécifique. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Informations générales

Matériel applicable

Les procédures décrites dans ce document s'appliquent à ce matériel :

• Nexus SmartNIC X10
• Nexus SmartNIC X10-HPT
• Carte réseau intelligente Nexus X10-GM
• Nexus SmartNIC X25
• Nexus SmartNIC X40
• Nexus SmartNIC X100
• Nexus SmartNIC V5P
• Nexus SmartNIC V9P

Dépannage de l'installation matérielle Nexus SmartNIC

Cette section du document couvre les étapes utilisées pour dépanner les problèmes d'installation matérielle des cartes d'interface réseau à faible latence Nexus SmartNIC. Suivez cette section du document lorsque le système d'exploitation hôte (généralement une distribution Linux ou Windows Server) ne reconnaît pas une carte Nexus SmartNIC comme périphérique PCI Express valide.

Étape 1 : vérification de l’installation matérielle

Les cartes d'interface réseau Nexus SmartNIC doivent être correctement installées dans un logement PCI Express (PCIe) sur la carte mère ou la carte de montage/fille de l'hôte. Pour plus d'informations sur l'installation d'une carte PCIe, consultez le manuel de votre hôte fourni par le fabricant.

Pour plus d'informations sur l'installation des cartes PCIe sur les serveurs Cisco UCS, reportez-vous à la documentation suivante :

• Guide d'installation et de maintenance du serveur Cisco UCS C220 M5
• Guide d'installation et de maintenance du serveur Cisco UCS C240 M5

Étape 2 : vérification de la compatibilité des logements PCI Express

Toutes les cartes d'interface réseau Nexus SmartNIC doivent être installées dans un logement compatible PCIe 3.0. En outre, un logement PCIe x8 avec 49 broches au minimum doit être utilisé pour connecter toutes les cartes d'interface réseau Nexus SmartNIC. Pour plus d'informations sur la conformité des logements PCIe à ces spécifications, consultez le manuel de votre hôte fourni par le fabricant.

Pour plus d'informations sur la spécification des logements PCIe sur les serveurs Cisco UCS, reportez-vous au tableau suivant et à la documentation associée :

Étape 3 : vérification de l'installation dans le logement PCI Express actif

Une carte Nexus SmartNIC doit être correctement insérée dans un logement PCI Express connecté à un processeur actif et installé (unité centrale). Si un hôte est équipé de plusieurs sockets de processeur où un seul socket dispose d'un processeur (également appelé « configuration à processeur unique »), tous les logements PCIe peuvent ne pas être actifs et fonctionnels. Pour plus d'informations sur les logements PCIe activés dans une configuration à processeur unique, consultez le manuel de votre hôte fourni par le fabricant.

Pour plus d'informations sur les logements PCIe actifs sur les serveurs Cisco UCS dans une configuration à processeur unique, reportez-vous à ce tableau et à la documentation de support :

Étape 4. Vérification de l'alimentation de la carte SmartNIC Nexus

Chaque carte d'interface réseau Nexus SmartNIC comporte un certain nombre de voyants (diodes électroluminescentes) situés sur le support PCIe. Ces voyants sont généralement visibles de l'extérieur de l'hôte. Chaque port SFP+ et QSFP de la carte d'interface réseau est associé à un voyant LED plus grand. Ces voyants sont collectivement appelés voyants de port.

Sur les cartes d'interface réseau dotées uniquement de ports SFP+, une DEL rouge plus petite est présente et associée au connecteur PPS (à l'exception de la carte Nexus SmartNIC X10-GM, où la DEL rouge plus petite est associée à l'état d'horloge Grand Master). Ce voyant est appelé voyant PPS.

Remarque : Les cartes d'interface réseau Nexus SmartNIC équipées de ports QSFP n'ont pas de voyant PPS.

En résumé, reportez-vous au tableau ci-dessous :

Lorsqu'une carte d'interface réseau Nexus SmartNIC est mise sous tension pour la première fois avec l'hôte, tous les voyants de la carte d'interface réseau doivent clignoter momentanément. Si aucun voyant n'émet de lumière à tout moment après la mise sous tension de l'hôte, cela indique que la carte d'interface réseau Nexus SmartNIC n'est pas correctement alimentée par le bus PCIe. Résolvez ce problème en suivant cette procédure :

1. Vérifiez si le logement PCIe utilisé fonctionne avec d'autres périphériques connus pour fonctionner correctement. Idéalement, il faudrait tester avec une autre carte d'interface réseau.
2. Vérifiez si la carte d'interface réseau Nexus SmartNIC fonctionne sans problème dans un autre emplacement PCIe connu pour être fonctionnel.
3. Vérifiez si la carte d'interface réseau Nexus SmartNIC fonctionne sans problème dans un logement PCIe qui est reconnu fonctionnel sur un autre hôte qui est reconnu fonctionnel.

Si la carte d'interface réseau Nexus SmartNIC ne parvient pas à être alimentée quel que soit le logement PCIe et l'hôte utilisés, contactez le TAC Cisco pour obtenir des informations de dépannage supplémentaires.

Étape 5. Vérification de l’intégrité du micrologiciel

Comme indiqué précédemment à l'étape 4, chaque carte d'interface réseau Nexus SmartNIC peut comporter deux types de voyants :

• DEL de port
• DEL PPS

Lorsqu'aucun module SFP+/QSFP n'est inséré dans les ports de la carte d'interface réseau, ces voyants doivent rester éteints après le flash momentané décrit à l'étape 4 lorsque la carte d'interface réseau est mise sous tension pour la première fois.

Il existe trois scénarios courants dans lesquels ce n'est pas le cas en raison d'un micrologiciel endommagé ou manquant :

• Si les DEL de port et de PPS restent allumées après le clignotement momentané lorsqu'aucun module SFP+/QSFP n'est inséré et que le système d'exploitation hôte ne reconnaît pas la carte d'interface réseau comme un périphérique PCIe valide (par exemple, via la commande lspci), le micrologiciel de la carte d'interface réseau Nexus SmartNIC peut avoir besoin d'être récupéré. Suivez la procédure de récupération du micrologiciel de la carte Nexus SmartNIC et chargez une nouvelle version du micrologiciel sur la carte Nexus SmartNIC. Si cela ne résout pas le problème, contactez le TAC Cisco pour obtenir des informations de dépannage supplémentaires.

• Si une carte d'interface réseau Nexus SmartNIC est équipée d'un voyant PPS et que ce voyant est allumé en permanence, le micrologiciel existant chargé sur la carte est endommagé et la carte est passée en mode de récupération du micrologiciel. Vous devez suivre le processus de mise à jour du micrologiciel de la carte SmartNIC Nexus pour utiliser la carte d'interface réseau normalement. Si cela ne résout pas le problème, contactez le TAC Cisco pour obtenir des informations de dépannage supplémentaires.

• Si une carte d'interface réseau Nexus SmartNIC n'est pas équipée d'un voyant PPS et que les voyants des ports alternent continuellement entre éteint et orange, le micrologiciel existant chargé sur la carte est endommagé et la carte est passée en mode de récupération du micrologiciel. Vous devez suivre le processus de mise à jour du micrologiciel de la carte SmartNIC Nexus pour utiliser la carte d'interface réseau normalement. Si cela ne résout pas le problème, contactez le TAC Cisco pour obtenir des informations de dépannage supplémentaires.

Étape 6. Vérification de la détection PCI Express du système d'exploitation hôte

Vous pouvez confirmer que le système d'exploitation hôte peut détecter avec succès une carte d'interface réseau Nexus SmartNIC via le bus PCIe avec la commande lspci. L'ID de fournisseur PCI (VID) 16 bits d'Exablaze est 0x1ce4, qui peut être utilisé pour sonder les périphériques Nexus SmartNIC PCIe pour obtenir des informations. Ceci est démontré dans l'exemple ci-dessous :

[root@host ~]# lspci -d 1ce4:
01:00.0 Ethernet controller: Exablaze ExaNIC X10

Pour obtenir des informations plus détaillées sur la carte PCIe, ajoutez l'indicateur -v verbose à la commande lspci. Ceci est démontré dans l'exemple ci-dessous :

[root@host ~]# lspci -d 1ce4: -v
01:00.0 Ethernet controller: Exablaze ExaNIC X10
Subsystem: Exablaze ExaNIC X10
Flags: bus master, fast devsel, latency 0, IRQ 30
Memory at 92000000 (32-bit, non-prefetchable) [size=8M]
Memory at 92800000 (64-bit, non-prefetchable) [size=4M]
Capabilities: [80] Power Management version 3
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [c0] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [1b8] Latency Tolerance Reporting
Capabilities: [300] #19
Capabilities: [340] Vendor Specific Information: ID=0001 Rev=0 Len=02c <?>
Kernel modules: exanic

Des informations encore plus détaillées peuvent être affichées en ajoutant l'indicateur -vv verbose à la commande lspci. Ceci est démontré dans l'exemple ci-dessous :

[root@host ~]# lspci -d 1ce4: -vv
01:00.0 Ethernet controller: Exablaze ExaNIC X10
    Subsystem: Exablaze ExaNIC X10
    Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
    Latency: 0
    Interrupt: pin A routed to IRQ 30
    Region 0: Memory at 92000000 (32-bit, non-prefetchable) [size=8M]
    Region 2: Memory at 92800000 (64-bit, non-prefetchable) [size=4M]
    Capabilities: [80] Power Management version 3
        Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
        Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
    Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit+
        Address: 00000000fee003b8  Data: 0000
    Capabilities: [c0] Express (v2) Endpoint, MSI 00
        DevCap:    MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
            ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 75.000W
        DevCtl:    Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
            RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
            MaxPayload 128 bytes, MaxReadReq 512 bytes
        DevSta:    CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
        LnkCap:    Port #0, Speed 8GT/s, Width x8, ASPM not supported, Exit Latency L0s unlimited, L1 unlimited
            ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp+
        LnkCtl:    ASPM Disabled; RCB 64 bytes Disabled- CommClk+
            ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
        LnkSta:    Speed 8GT/s, Width x8, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
        DevCap2: Completion Timeout: Range B, TimeoutDis+, LTR+, OBFF Not Supported
        DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
        LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis-
             Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
             Compliance De-emphasis: -6dB
        LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete+, EqualizationPhase1+
             EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
    Capabilities: [100 v2] Advanced Error Reporting
        UESta:    DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
        UEMsk:    DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
        UESvrt:    DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
        CESta:    RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
        CEMsk:    RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
        AERCap:    First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-
    Capabilities: [1b8 v1] Latency Tolerance Reporting
        Max snoop latency: 0ns
        Max no snoop latency: 0ns
    Capabilities: [300 v1] #19
    Capabilities: [340 v1] Vendor Specific Information: ID=0001 Rev=0 Len=02c <?>
    Kernel modules: exanic

Si la commande lspci affiche des informations sur la carte d'interface réseau Nexus SmartNIC, cela indique que le système d'exploitation hôte a correctement détecté la carte d'interface réseau Nexus SmartNIC via le bus PCIe. À l'avenir, on peut installer les pilotes du logiciel Nexus SmartNIC et commencer à utiliser la carte.

Dépannage de l'installation du pilote logiciel Nexus SmartNIC

Cette section du document couvre les étapes utilisées pour dépanner les problèmes d'installation du pilote logiciel de la carte d'interface réseau à faible latence Nexus SmartNIC. Suivez cette section du document lorsque le système d'exploitation hôte (généralement une distribution Linux ou Windows Server) reconnaît une carte Nexus SmartNIC comme périphérique PCI Express valide, mais que le système d'exploitation hôte ne reconnaît pas les ports de la carte Nexus SmartNIC comme interface réseau valide. Un exemple de ceci est montré dans le résultat ici :

[root@host ~]# ls /dev/exanic*
ls: cannot access /dev/exanic*: No such file or directory

Cette section du document suppose qu'une erreur s'est produite lors de la tentative d'installation des pilotes du logiciel Nexus SmartNIC, comme décrit dans le guide d'installation du logiciel Nexus SmartNIC.

Toutes les commandes de cette procédure sont exécutées à partir du compte Linux racine. Si vous n'utilisez pas le compte Linux racine pour suivre cette procédure, vous devrez peut-être utiliser la commande sudo pour élever les privilèges de sécurité de votre compte à ceux d'un superutilisateur.

Étape 1 : vérification de l’utilisation du pilote

Si le noyau du système d'exploitation hôte a chargé un pilote logiciel pour une carte d'interface réseau Nexus SmartNIC, la commande lspci avec l'indicateur -v verbose affichera le pilote en cours d'utilisation. Il est possible d'interroger des périphériques à l'aide de l'ID de fournisseur PCI d'Exablaze (0x1ce4) pour afficher des informations spécifiques aux périphériques Nexus SmartNIC PCIe. Un exemple de ceci est montré dans le résultat ici :

[root@host ~]# lspci -d 1ce4: -v | egrep Kernel.driver
    Kernel driver in use: exanic

Si le noyau du système d'exploitation hôte n'a pas chargé le pilote logiciel, alors cette ligne "Pilote de noyau en cours d'utilisation" sera omise dans le résultat de la commande lspci -d 1ce4: -v.

Étape 2 : vérification de l’installation du pilote

Vérifier l'installation du pilote à partir du RPM (apt, yum, etc.)

Comme décrit dans le guide d'installation du logiciel Nexus SmartNIC, les pilotes du logiciel Nexus SmartNIC peuvent être installés par l'intermédiaire d'un gestionnaire de package (tel que apt, yum, ou directement par rpm). Si vous avez installé les pilotes du logiciel ExaNIC avec cette méthode, vous pouvez vérifier que tous les fichiers ont été correctement installés comme indiqué ci-dessous.

Selon l'architecture CPU de votre hôte, le fichier de bibliothèque libexanic.a peut être dans /usr/lib/ ou dans /usr/lib64/. Voici un exemple d'architecture de CPU x86 (32 bits) :

[root@host ~]# ls /usr/lib/ | grep exanic
libexanic.a

Voici un exemple d'architecture de CPU x86_64 (64 bits) :

[root@host ~]# ls /usr/lib64/ | grep exanic
libexanic.a

Assurez-vous que les fichiers d'en-tête de bibliothèque Nexus SmartNIC sont présents dans le répertoire /usr/include/exanic/. Ceci est montré dans l'exemple ci-dessous :

[root@host ~]# ls /usr/include/exanic/ -1
config.h
const.h
exanic.h
fifo_if.h
fifo_rx.h
fifo_tx.h
filter.h
firewall.h
hw_info.h
ioctl.h
pcie_if.h
port.h
register.h
time.h
util.h

Assurez-vous que les utilitaires binaires de la carte réseau intelligente Nexus se trouvent dans le répertoire /usr/bin/. Ceci est montré dans l'exemple ci-dessous :

[root@host ~]# ls /usr/bin/ -1 | grep exanic-
exanic-capture
exanic-clock-check
exanic-clock-sync
exanic-config
exanic-fwupdate

Enfin, assurez-vous que le fichier de module exanic.ko.xz est présent dans le répertoire /lib/modules/`uname -r`/extra/. Notez que la commande inline `uname -r` insère automatiquement votre version actuelle du noyau dans le répertoire. Cette commande est entourée d'accents graves (`) et non de guillemets simples. L'exemple suivant illustre cette commande :

[root@host ~]# ls /lib/modules/\`uname -r\`/extra/ | grep exanic
exanic.ko.xz

Vérification De L'Installation Du Pilote Source

Comme décrit dans le Guide d'installation du logiciel Nexus SmartNIC, les pilotes du logiciel Nexus SmartNIC peuvent être construits et installés à partir du code source. Si vous avez installé les pilotes du logiciel Nexus SmartNIC avec cette méthode, vous pouvez vérifier que tous les fichiers ont été correctement installés, comme indiqué dans les exemples ci-dessous.

Assurez-vous que le fichier de bibliothèque libexanic.a est présent dans le répertoire /usr/local/lib/. Ceci est montré dans l'exemple ici :

[root@host ~]# ls /usr/local/lib/ | grep exanic
libexanic.a

Assurez-vous que les fichiers d'en-tête de la bibliothèque Nexus SmartNIC sont présents dans le répertoire /usr/local/include/exanic/. L'exemple suivant illustre cette situation :

[root@host ~]# ls /usr/local/include/exanic/ -1
config.h
const.h
exanic.h
fifo_if.h
fifo_rx.h
fifo_tx.h
filter.h
firewall.h
hw_info.h
ioctl.h
pcie_if.h
port.h
register.h
time.h
util.h

Assurez-vous que les utilitaires binaires SmartNIC de Nexus se trouvent dans le répertoire /usr/local/bin/. Ceci est illustré dans l'exemple ci-dessous :

[root@host ~]# ls /usr/local/bin -1 | grep exanic-
exanic-capture
exanic-clock-check
exanic-clock-sync
exanic-config
exanic-fwupdate

Enfin, assurez-vous que le fichier de module exanic.ko est présent dans le répertoire /lib/modules/`uname -r`/extra/. Notez que la commande inline `uname -r` insère automatiquement votre version actuelle du noyau dans le répertoire. Cette commande est entourée d'accents graves (`) et non de guillemets simples. L'exemple suivant illustre cette commande :

[root@host ~]# ls /lib/modules/`uname -r`/extra | grep exanic
exanic.ko

Étape 3. Tentative De Chargement Du Pilote Logiciel

Le pilote logiciel Nexus SmartNIC peut être chargé manuellement avec la commande modprobe exanic.

Si les pilotes Nexus SmartNIC sont chargés, le noyau Linux le reconnaîtra comme un périphérique. Vous pouvez vérifier ceci avec la commande ls /dev/exanic*, qui affichera tous les périphériques Nexus SmartNIC reconnus. Ceci est montré dans l'exemple ici :

[root@host ~]# ls /dev/exanic*
/dev/exanic0

Si les pilotes Nexus SmartNIC ne sont pas chargés avec succès, la commande modprobe exanic peut ou ne peut pas retourner une erreur. Les sous-sections ci-dessous décrivent comment dépanner les erreurs renvoyées par cette commande.

"modprobe : FATAL : Module exanic introuvable" Message d'erreur

Ce message d'erreur peut être causé par deux problèmes différents décrits dans les sous-sections ci-dessous.

Dépendances de module de noyau incorrectement mappées

Le système d'exploitation hôte ne peut pas localiser le module construit pour le noyau en cours d'exécution. Par conséquent, le système d'exploitation hôte ne peut pas charger le module dans le système avec la commande modprobe exanic. Ceci peut être résolu avec la commande depmod -a, qui créera une carte des dépendances du module noyau. Le module du noyau peut alors être chargé avec la commande modprobe exanic.

Module de noyau non construit par DKMS

DKMS (Dynamic Kernel Module Support) permet aux modules du noyau d'être automatiquement reconstruits chaque fois qu'un nouveau noyau du système d'exploitation est installé. Si DKMS n'a pas construit le module de noyau Nexus SmartNIC, alors il est possible que le module de noyau Nexus SmartNIC ait été compilé précédemment pour une version de noyau de système d'exploitation différente.

Pour que DKMS fonctionne comme prévu, les paquets kernel-devel et kernel-headers doivent être installés en utilisant le gestionnaire de paquets du système d'exploitation hôte. Un exemple de la façon de confirmer si ce paquet est installé avec la commande yum list est montré dans le résultat ici :

[root@host ~]$ yum list kernel-devel
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: mirror.internode.on.net
 * epel: ucmirror.canterbury.ac.nz
 * extras: mirror.internode.on.net
 * updates: centos.mirror.serversaustralia.com.au
Installed Packages
kernel-devel.x86_64                                      3.10.0-1062.el7                                            @base
kernel-devel.x86_64                                      3.10.0-1062.12.1.el7                                       @updates

[root@host ~]$ yum list kernel-headers
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: mirror.internode.on.net
 * epel: ucmirror.canterbury.ac.nz
 * extras: mirror.internode.on.net
 * updates: centos.mirror.serversaustralia.com.au
Installed Packages
kernel-headers.x86_64                                     3.10.0-1062.12.1.el7                                      @updates

Reportez-vous au manuel du gestionnaire de packages de votre système d'exploitation hôte pour vérifier comment déterminer si un package spécifique est installé.

Vous pouvez confirmer si le module noyau SmartNIC de Nexus est correctement ajouté, construit et installé par DKMS avec la commande dkms status. Un exemple du résultat de cette commande dans un état de fonctionnement attendu est montré ici :

[root@host ~]# dkms status
exanic, 2.4.1-1.el8, 3.10.0-957.27.2.el7.x86_64, x86_64: installed

Si cette sortie montre que le module noyau Nexus SmartNIC est dans un état autre que « installed », il faudra soit construire soit installer le module noyau Nexus SmartNIC à l'aide de DKMS.

Si le module de noyau Nexus SmartNIC est ajouté mais pas généré, utilisez la commande dkms build -m exanic -v {version} pour générer le module de noyau Nexus SmartNIC. Un exemple de cette commande est présenté ici avec la version logicielle 2.4.1-1.el7 :

[root@host ~]$ dkms build -m exanic -v 2.4.1-1.el7

Kernel preparation unnecessary for this kernel.  Skipping...

Building module:
cleaning build area...
make -j16 KERNELRELEASE=3.10.0-1062.el7.x86_64 -C modules KDIR=/lib/modules/3.10.0-1062.el7.x86_64/build...
cleaning build area...

DKMS: build completed.

Si le module de noyau Nexus SmartNIC est construit mais pas installé, utilisez la commande dkms install -m exanic -v {version} pour installer le module de noyau Nexus SmartNIC. Un exemple de cette commande est présenté ici avec la version logicielle 2.4.1-1.el7 :

[root@host ~]$ dkms install -m exanic -v 2.4.1-1.el7

exanic.ko.xz:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/3.10.0-1062.el7.x86_64/extra/

exasock.ko.xz:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/3.10.0-1062.el7.x86_64/extra/
Adding any weak-modules

depmod...

DKMS: install completed.

Une fois que le module de noyau Nexus SmartNIC est construit et installé avec DKMS, le module de noyau Nexus SmartNIC peut alors être chargé avec la commande modprobe exanic.

"modprobe : Clé requise non disponible" Message d'erreur

Ce message d'erreur s'affiche sur les hôtes équipés du micrologiciel UEFI (Unified Extensible Firmware Interface) dont le protocole Secure Boot est activé. Le démarrage sécurisé empêche le chargement des pilotes du noyau qui ne sont pas signés avec une signature numérique acceptable. Par conséquent, quand on essaie de charger le pilote du noyau Nexus SmartNIC avec la commande modprobe exanic, le protocole Secure Boot empêche le pilote du noyau d'être chargé.

Pour résoudre ce problème, le protocole Secure Boot doit être désactivé dans l'UEFI de l'hôte. Pour plus d'informations sur la désactivation du protocole Secure Boot dans l'UEFI de votre hôte, consultez le manuel de votre hôte fourni par le fabricant.

Étape 4 : confirmation du fonctionnement de l'utilitaire Nexus SmartNIC

La commande exanic-config sans argument peut être utilisée pour afficher des informations de base sur les cartes d'interface réseau Nexus SmartNIC installées sur l'hôte après le chargement des pilotes de noyau Nexus SmartNIC dans le système d'exploitation. Voici un exemple de ce résultat :

[root@host ~]$ exanic-config

Device exanic1:
Hardware type: ExaNIC X10
Temperature: 38.8 C VCCint: 0.95 V VCCaux: 1.83 V
Function: network interface
Firmware date: 20180409 (Mon Apr 9 23:27:40 2018)
PPS port: input, termination disabled
Port 0:
Interface: enp175s0
Port speed: 10000 Mbps
Port status: enabled, SFP present, signal detected, link active
MAC address: 64:3f:5f:xx:xx:xx
RX packets: 11778 ignored: 0 error: 0 dropped: 0
TX packets: 11836
Port 1:
Interface: enp175s0d1
Port speed: 10000 Mbps
Port status: enabled, SFP present, signal detected, link active
MAC address: 64:3f:5f:xx:xx:xx
RX packets: 11836 ignored: 0 error: 0 dropped: 0
TX packets: 11778

Si la commande/utilitaire exanic-config renvoie des informations pertinentes sur les cartes d'interface réseau Nexus SmartNIC installées, l'installation du matériel et du pilote logiciel de la carte Nexus SmartNIC a réussi.

Informations connexes

• Installation du périphérique Nexus SmartNIC
• Guide d'installation et de maintenance du serveur Cisco UCS C240 M5
• Guide d'installation et de maintenance du serveur Cisco UCS C220 M5
• Guide d'analyse comparative Nexus SmartNIC