Comprendre le DCBX
Le protocole DCBX (Data Center Bridging Capability Exchange Protocol) est une extension de LLDP (Link Layer Data Protocol). Si vous désactivez LLDP sur une interface, cette interface ne peut pas exécuter DCBX. Si vous essayez d’activer DCBX sur une interface sur laquelle LLDP est désactivé, l’opération de validation de configuration échoue. Les équipements de pontage de centre de données (DCB) utilisent le DCBX pour échanger des informations de configuration avec des pairs directement connectés.
Cette rubrique décrit :
Bases DCBX
DCBX peut :
Découvrez les capacités DCB des pairs.
Détectez les erreurs de configuration des fonctionnalités DCB ou les incompatibilités entre les pairs.
Configurez les fonctionnalités DCB sur les pairs.
Vous pouvez configurer le fonctionnement DCBX pour le contrôle des flux basé sur les priorités (PFC), les applications de couche 2 et de couche 4 telles que FCoE et iSCSI, et ETS. DCBX est activé ou désactivé par interface.
Les commutateurs QFX5200 et QFX5210 ne prennent pas en charge la planification hiérarchique de sélection de transmission améliorée (ETS). Utilisez la planification des ports pour gérer la bande passante sur ces commutateurs.
Par défaut, pour PFC et ETS, DCBX négocie automatiquement l’état et la configuration administratifs avec chaque pair connecté de chaque interface. Pour permettre la négociation DCBX pour les applications, vous devez configurer les applications, les mapper aux points de code IEEE 802.1p dans un plan d’application et appliquer le plan des applications aux interfaces.
L’application FCoE doit uniquement être incluse dans un plan d’application lorsque vous souhaitez qu’une interface échange le type, la longueur et les valeurs (TLV) avec d’autres applications en plus de FCoE. Si le FCoE est la seule application que vous voulez une interface de publicité, vous n’avez pas besoin d’utiliser un plan d’application. Pour l’ETS, DCBX pousse la configuration du commutateur à ses pairs s’ils sont configurés pour apprendre la configuration à partir du commutateur (à moins que vous ne désactiviez l’envoi de la recommandation ETS TLV sur les interfaces en mode IEEE DCBX).
Vous pouvez remplacer le comportement par défaut de PFC, d’ETS ou de toutes les applications mappées à une interface en désactivant l’autonegotiation pour forcer une interface à activer ou désactiver cette fonctionnalité. Vous pouvez également désactiver l’automatisation DCBX pour les applications sur une interface en excluant ces applications du plan d’application que vous appliquez à cette interface ou en supprimant le plan d’application de l’interface.
Le comportement d’autonegotiation par défaut pour les applications mappées à une interface est :
DCBX est activé sur l’interface si l’équipement homologue connecté prend également en charge DCBX.
DCBX est désactivé sur l’interface si l’équipement peer connecté ne prend pas en charge DCBX.
Lors de la négociation des fonctionnalités, le commutateur peut pousser la configuration PFC à un homologue joint si celui-ci est configuré comme « prêt » à apprendre la configuration PFC auprès d’autres pairs. Le commutateur Juniper Networks ne prend pas en charge l’autoprovisionnement et ne modifie pas sa configuration pendant l’autonegotiation pour correspondre à la configuration homologue. (Le commutateur Juniper n’est pas « prêt » à apprendre la configuration PFC de ses pairs.)
Lorsqu’un port avec DCBX activé commence à échanger des entrées de type, de longueur et de valeur (TLV), les TLV LLDP optionnels sur ce port ne sont pas annoncés aux voisins, de sorte que le commutateur peut interagir avec une plus grande variété d’adaptateurs réseau convergés (CCA) et de commutateurs de couche 2 qui prennent en charge DCBX.
Modes et assistance DCBX
Cette section décrit la prise en charge du DCBX :
- Modes DCBX (versions)
- Autonegotiation
- Prise en charge par CNA des modes DCBX
- Prise en charge de l’interface DCBX
Modes DCBX (versions)
Les deux modes DCBX les plus courants sont pris en charge :
IEEE DCBX : la dernière version de DCBX. Les TLV ont différents sous-types (par exemple, le sous-type de configuration ETS TLV est 9) ; l’identifiant unique (OUA) IEEE DCBX est 0x0080c2.
DCBX version 1.01 — La version CEE (Converged Enhanced Ethernet) de DCBX. Il a un sous-type de 2 et un OUI de 0x001b21.
IEEE DCBX et DCBX version 1.01 diffèrent principalement par le format de trame. DCBX version 1.01 utilise un TLV qui inclut toutes les informations d’attributS DCBX, qui sont envoyées en tant que sous-TLV. IEEE DCBX utilise une TLV unique pour chaque attribut DCB.
Le commutateur ne prend pas en charge les versions DCBX pré-CEE (pré-DCB). Les anciennes versions de DCBX non prises en charge ont un sous-type de 1 et une oui de 0x001b21. Le commutateur supprime les trames LLDP qui contiennent des TLV DCBX pré-CEE.
Le tableau 1 résume les différences entre IEEE DCBX et DCBX version 1.01, y compris show command output :
Caractéristique |
IEEE DCBX |
DCBX version 1.01 |
|---|---|---|
OUI |
0x0080c2 |
0x001b21 |
Format de trame |
Envoie une TLV distincte et unique pour chaque attribut DCBX. Par exemple, IEEE DCBX utilise des TLV distinctes pour l’ETS, le PFC et chaque application. Les informations de configuration et de recommandation sont envoyées dans différentes TLV |
Envoie une TLV qui inclut toutes les informations d’attributS DCBX organisées en sous-TLV. Le bit « prêt » détermine si une interface peut ou non modifier sa configuration pour qu’elle corresponde à l’homologue connecté. |
Configuration symétrique/asymétrique avec peer |
Asymétrique ou symétrique |
Symétrique uniquement |
Différences dans le |
|
|
Vous pouvez configurer des interfaces pour utiliser les modes DCBX suivants :
IEEE DCBX : l’interface utilise IEEE DCBX quelle que soit la configuration sur l’homologue connecté.
DCBX version 1.01 : l’interface utilise DCBX version 1.01, quelle que soit la configuration sur l’homologue connecté.
Autonegotiation : l’interface négocie automatiquement avec l’homologue connecté pour déterminer la version DCBX utilisée par les pairs. L’autonegotiation est le mode DCBX par défaut.
Si vous configurez un mode DCBX sur une interface, l’interface ignore les unités de données du protocole DCBX (PDUs) qu’elle reçoit de l’homologue connecté si les PDU ne correspondent pas à la version DCBX configurée sur l’interface. Par exemple, si vous configurez une interface pour utiliser IEEE DCBX et que l’homologue connecté envoie des PDU LLDP version 1.01 DCBX, l’interface ignore les PDU de la version 1.01. Si vous configurez une interface pour utiliser DCBX version 1.01 et que l’homologue envoie des PDU LLDP IEEE DCBX, l’interface ignore les PDU IEEE DCBX.
Sur les interfaces qui utilisent le mode IEEE DCBX, la show dcbx neighbors interface interface-name commande opérationnelle n’inclut pas l’état opérationnel de l’application, du PFC ou de l’ETS dans la sortie.
Autonegotiation
L’autonegotiation est le mode DCBX par défaut. Chaque interface négocie automatiquement avec son homologue connecté pour déterminer la version DCBX que les deux interfaces utilisent pour échanger des informations DCBX.
Lorsqu’une interface se connecte à son interface peer, l’interface annonce des TLV IEEE DCBX à l’homologue. Si l’interface reçoit un PDU IEEE DCBX de l’homologue, l’interface définit le mode DCBX comme IEEE DCBX. Si l’interface reçoit trois TLV DCBX version 1.01 de la part de l’homologue, l’interface définit DCBX version 1.01 comme mode DCBX.
L’autonegotiation fonctionne légèrement différemment sur les commutateurs autonomes par rapport aux systèmes QFabric :
Commutateurs autonomes : lorsqu’une interface se connecte à son interface peer, l’interface annonce les TLV IEEE DCBX au pair. Si l’interface reçoit un TLV IEEE DCBX de l’homologue, l’interface définit IEEE DCBX comme mode DCBX. Si l’interface reçoit trois TLV DCBX version 1.01 consécutives de la part de l’homologue, l’interface définit DCBX version 1.01 comme mode DCBX.
Système QFabric : lorsqu’une interface se connecte à son interface peer, l’interface annonce des TLV DCBX version 1.01 à l’homologue. Si l’interface reçoit un TLV IEEE DCBX de l’homologue, l’interface définit IEEE DCBX comme mode DCBX. Si l’interface reçoit trois TLV consécutives DCBX version 1.01 de la part de l’homologue, l’interface conserve DCBX version 1.01 comme mode DCBX.
Si les volets de liaison ou le processus LLDP redémarrent, l’interface recommence le processus d’autonegotiation. L’interface n’utilise pas le dernier mode de communication DCBX reçu.
Prise en charge par CNA des modes DCBX
Différents fournisseurs de CNA prennent en charge différentes versions et fonctionnalités de DCBX. La configuration DCBX que vous utilisez sur les interfaces de commutation dépend des fonctionnalités DCBX que les CCA de votre réseau prennent en charge.
Prise en charge de l’interface DCBX
Vous pouvez configurer DCBX sur des interfaces 10 Gigabit Ethernet et sur des interfaces de groupe d’agrégation de liens (LAG) dont les interfaces membres sont toutes des interfaces 10 Gigabit Ethernet.
Types d’attributs DCBX
DCBX a trois types d’attributs :
Informations : ces attributs sont échangés à l’aide de LLDP, mais n’affectent pas l’état ou le fonctionnement du DCBX ; ne communiquent des informations qu’au pair. Par exemple, les TLV prioritaires pour les applications sont des TLV informationnelles.
Asymétrique : les valeurs de ces types d’attributs ne doivent pas forcément être les mêmes sur les interfaces homologues connectées. Les pairs échangent des attributs asymétriques lorsque les valeurs d’attribut peuvent différer sur chaque interface peer. Les configurations d’interface homologues peuvent correspondre ou différer. Par exemple, les TLV de configuration et de recommandation d’ETS sont des TLV asymétriques.
Symétrique : l’intention est que les valeurs de ces types d’attributs soient les mêmes sur les deux interfaces homologues connectées. Les interfaces homologues échangent des attributs symétriques pour garantir une configuration DCBX symétrique pour ces attributs. Par exemple, les TLV de configuration PFC sont des TLV symétriques.
Les sections suivantes décrivent les attributs DCBX asymétriques et symétriques :
Attributs asymétriques
DCBX transmet des attributs asymétriques entre les interfaces homologues connectées pour communiquer des informations sur les paramètres de ces attributs (fonctionnalités). La configuration résultante d’un attribut peut être différente sur chaque pair, de sorte que les paramètres configurés sur une interface peuvent ne pas correspondre aux paramètres de l’interface peer connectée.
Il existe deux types de TLV d’attributs asymétriques :
Configuration TLV : les TLV de configuration communiquent l’état opérationnel actuel et l’état du bit « prêt ». Le bit « prêt » indique si l’interface est prête ou non à accepter et à utiliser la configuration à partir de l’interface pair. Si une interface est « prête », l’interface utilise la configuration qu’elle reçoit de l’interface peer. (La configuration de l’interface peer peut remplacer la configuration sur l’interface « prête ». Si une interface n’est pas prête, la configuration de l’interface ne peut pas être remplacée par la configuration d’interface peer.
Recommandation TLV : les TLV de recommandation communiquent les paramètres que l’interface recommande d’utiliser pour l’interface pair connectée. Lorsqu’une interface envoie une recommandation TLV, si l’homologue connecté est « prêt », l’homologue connecté modifie sa configuration pour qu’elle corresponde aux paramètres du TLV de recommandation.
Attributs symétriques
DCBX transmet des attributs symétriques entre les interfaces homologues connectées pour communiquer les informations de paramètres sur ces attributs (fonctionnalités), l’objectif étant que les deux interfaces utilisent la même configuration. L’intention est que les paramètres configurés sur une interface doivent correspondre aux paramètres de l’interface peer connectée.
Il existe un type d’attribut symétrique TLV, le TLV de configuration. Comme pour les attributs asymétriques, les TLV de configuration d’attributs symétriques communiquent l’état opérationnel actuel et l’état du bit « prêt ». Les interfaces « prêtes » utilisent les valeurs de paramètres d’interface homologues pour l’attribut. (La configuration d’attributs de l’homologue remplace la configuration sur l’interface « prête ».
Protocole d’application DCBX TLV Exchange
DCBX annonce les capacités du commutateur pour les applications de couche 2 telles que FCoE et les applications de couche 4 telles que iSCSI :
- Protocole d’application TLV Exchange
- Protocole d’application FCoE TLV Exchange
- Désactiver le protocole d’application TLV Exchange
Protocole d’application TLV Exchange
Pour toutes les applications, DCBX annonce l’état de l’application et les points de code IEEE 802.1p sur les interfaces auxquelles l’application est mappée. Si une application n’est pas mappée à une interface, cette interface n’annonce pas les TLV de l’application. Il existe une exception pour le protocole d’application FCoE TLV l’échange lorsque FCoE est la seule application que vous souhaitez que DCBX fasse de la publicité sur une interface.
Protocole d’application FCoE TLV Exchange
Le protocole TLV’échange pour l’application FCoE dépend de si FCoE est la seule application que vous souhaitez que l’interface fasse de la publicité ou si vous souhaitez que l’interface échange d’autres TLV d’application en plus des TLV FCoE.
Si FCoE est la seule application que vous souhaitez que DCBX fasse de la publicité sur une interface, DCBX échange par défaut des TLV du protocole d’application FCoE si l’interface :
Transporte le trafic FCoE (trafic mappé par la configuration CoS à la classe de transfert FCoE)
Dispose d’un profil de notification de congestion avec PFC activé sur la priorité FCoE (point de code IEEE 802.1p)
N’a pas de carte d’application
Si aucune configuration CoS pour FCoE n’est mappée à une interface, cette interface n’échange pas de TLV de protocole d’application FCoE.
Si vous voulez que DCBX annonce FCoE et d’autres applications sur une interface, vous devez spécifier toutes les applications, Y compris FCoE, dans un plan d’application, et appliquer le plan des applications aux interfaces souhaitées.
Si un plan d’application est appliqué à une interface, l’application FCoE doit être configurée explicitement dans le plan d’application, ou l’interface n’échange pas de TLV FCoE.
Lorsque DCBX annonce l’application FCoE, il annonce l’état FCoE et les points de code IEEE 802.1p. Si un équipement homologue connecté à une interface de commutateur ne prend pas en charge le FCoE, DCBX utilise l’autonegotiation pour marquer l’interface comme « FCoE vers le bas », et FCoE est désactivé sur cette interface.
Désactiver le protocole d’application TLV Exchange
Pour désactiver l’échange de protocole DCBX pour toutes les applications d’une interface, envoyez la set protocols dcbx interface interface-name applications no-auto-negotiation commande.
Vous pouvez également désactiver l’échange de protocole d’application DCBX pour les applications sur une interface en supprimant le plan d’application de l’interface ou en supprimant une application particulière du plan d’application. Toutefois, lorsque vous supprimez une application d’un plan d’application, le protocole d’application n’est plus échangé sur une interface qui utilise ce plan d’application.
DCBX et PFC
Après avoir activé le PFC sur une interface de commutateur, DCBX utilise l’autonegotiation pour contrôler l’état opérationnel de la fonctionnalité PFC.
Si l’équipement homologue connecté à l’interface prend en charge le PFC et est provisionné de manière compatible avec le commutateur, DCBX définit l’état opérationnel du PFC comme activé. Si l’équipement homologue connecté à l’interface ne prend pas en charge le PFC ou n’est pas provisionné de manière compatible avec le commutateur, DCBX définit l’état opérationnel sur désactivé. (PFC doit être symétrique.)
Si l’homologue annonce qu’il est « prêt » à apprendre sa configuration PFC à partir du commutateur, DCBX pousse la configuration PFC du commutateur vers l’homologue et ne vérifie pas l’état administratif du pair.
Vous pouvez remplacer manuellement le contrôle DCBX de l’état opérationnel des PFC par interface en désactivant l’autonegotiation. Si vous désactivez l’autonegotiation sur une interface sur laquelle vous avez configuré PFC, le PFC est activé sur cette interface, quelle que soit la configuration peer. Pour désactiver le PFC sur une interface, ne configurez pas PFC sur cette interface.
DCBX et ETS
Cette section décrit :
Publicité DCBX ETS par défaut
Si vous ne configurez pas ETS sur une interface, le commutateur crée automatiquement un groupe de priorité par défaut qui contient toutes les priorités (classes de transfert, qui représentent les files d’attente de sortie) et affecte 100 % de la bande passante de sortie de port à ce groupe de priorité. Le groupe de priorité par défaut est transparent. Il n’apparaît pas dans la configuration et est utilisé pour la publicité DCBX. DCBX annonce le groupe de priorité par défaut, ses priorités et la bande passante affectée.
Si vous configurez ETS sur une interface, DCBX annonce :
Chaque groupe prioritaire sur l’interface
Les priorités de chaque groupe de priorités
Les propriétés de bande passante de chaque groupe de priorité et de chaque priorité
Toute priorité sur cette interface qui ne fait pas partie d’un groupe de priorités configuré explicitement (ensemble de classes de transfert) est attribuée au groupe de priorité par défaut généré automatiquement et ne reçoit aucune bande passante. Si vous configurez ETS sur une interface, chaque classe de transfert (priorité) sur cette interface pour laquelle vous souhaitez transférer le trafic doit appartenir à un ensemble de classes de transfert (groupe de priorité).
Publicité ETS et configuration des pairs
Le DCBX ne contrôle pas l’état opérationnel de l’ETS (planification hiérarchique) du commutateur. Si l’homologue connecté est configuré comme « prêt », DCBX pousse la configuration ETS du commutateur aux pairs du commutateur si le TLV de recommandation ETS est activé (elle est activée par défaut). Si l’homologue ne prend pas en charge l’ETS ou n’est pas provisionné de manière cohérente avec le commutateur, DCBX ne modifie pas l’état opérationnel de l’ETS sur le commutateur. L’état opérationnel de l’ETS reste activé ou désactivé uniquement en fonction de la configuration hiérarchique de planification du commutateur et est activé par défaut.
Lorsque l’ETS est configuré, DCBX annonce les groupes prioritaires, les priorités dans les groupes prioritaires et la configuration de la bande passante pour les groupes prioritaires et les priorités. Toute priorité (essentiellement une classe ou une file d’attente de transfert) qui ne fait pas partie d’un groupe de priorité n’a pas de propriétés de planification et ne reçoit pas de bande passante.
Vous pouvez remplacer manuellement si DCBX annonce l’état ETS à l’homologue par interface en désactivant l’autonegotiation. Cela n’affecte pas l’état de l’ETS sur le commutateur ou sur l’homologue , mais il empêche le commutateur d’envoyer le TLV de recommandation ou le TLV de configuration à l’homologue connecté. Pour désactiver l’ETS sur une interface, ne configurez pas de groupes de priorité (ensembles de classes de transfert) sur l’interface.
TLV de recommandation ETS
La recommandation ETS TLV communique les paramètres ETS que le commutateur souhaite utiliser l’interface peer connectée. Si l’interface peer est « prête », elle modifie sa configuration pour qu’elle corresponde à celle de la recommandation ETS TLV. Par défaut, les interfaces de commutation envoient le TLV de recommandation ETS à l’homologue. Les paramètres communiqués sont les paramètres ETS sortants définis par la configuration de la planification hiérarchique sur l’interface.
Nous vous recommandons d’utiliser les mêmes paramètres ETS sur l’homologue connecté que sur l’interface du commutateur et de laisser la recommandation ETS TLV activée. Toutefois, sur les interfaces qui utilisent IEEE DCBX comme mode DCBX, si vous souhaitez une configuration asymétrique entre l’interface du commutateur et l’homologue connecté, vous pouvez désactiver la recommandation ETS TLV en incluant l’énoncé no-recommendation-tlv au niveau de la [edit protocols dcbx interface interface-name enhanced-transmission-selection] hiérarchie.
Vous pouvez désactiver la recommandation ETS TLV uniquement lorsque le mode DCBX sur l’interface est IEEE DCBX. Désactiver la recommandation ETS TLV n’a aucun effet si le mode DCBX sur l’interface est DCBX version 1.01. (IEEE DCBX utilise des TLV d’attributs d’application distincts, mais DCBX version 1.01 envoie tous les attributs d’application dans le même TLV et utilise des sous-TLV pour séparer les informations.)
Si vous désactivez le TLV de recommandation ETS, le commutateur envoie toujours le TLV de configuration ETS au pair connecté. Le résultat est que l’homologue connecté est informé de la configuration du commutateur DCBX ETS, mais même si l’homologue est « disposé », il ne modifie pas sa configuration pour correspondre à la configuration du commutateur. Il s’agit d’une configuration asymétrique: les deux interfaces peuvent avoir des valeurs de paramètres différentes pour l’attribut ETS.
Par exemple, si vous souhaitez qu’un CNA connecté à une interface de commutateur ait des allocations de bande passante différentes de celles de la configuration ETS du commutateur, vous pouvez désactiver l’TLV de recommandation ETS et configurer le CNA pour la bande passante souhaitée. L’interface du commutateur et l’assistant réseau échangent les paramètres de configuration, mais le CNA ne modifie pas sa configuration pour qu’elle corresponde à la configuration de l’interface du commutateur.